What would you like to be added:
KUDO supports multiple plan creation and enables us to see the status of a particular plan or trigger it. A plan uses single/multiple template YAML files. However, there is no way that we can see those rendered templates through the eyes of kudo for debugging purposes.
This can be done either by-
Printing the rendered template in the kudo-controller-manager pod logs just like dcos-commons does it for its templates.
Provide something like kubectl kudo plan trigger $plan --dry-run -o yaml .
Why is this needed:
Let's take an example scenario: If I manually trigger the validation plan of the zookeeper operator which uses validation.yaml to create a Job. I can only see the plan status.
This is okay but not helpful when I want to verify the template, see values of environment variables, or test any new operator locally. Having this option will be super helpful for debugging purposes. Of course, we can check the rendered templates by describing them or getting the logs. But having this feature will definitely prove to be productive in the overall dev and testing workflow.
What would you like to be added: KUDO supports multiple plan creation and enables us to see the
statusof a particular plan ortriggerit. A plan uses single/multiple template YAML files. However, there is no way that we can see those rendered templates through the eyes ofkudofor debugging purposes.This can be done either by-
kudo-controller-managerpod logs just likedcos-commonsdoes it for its templates.kubectl kudo plan trigger $plan --dry-run -o yaml.Why is this needed: Let's take an example scenario: If I manually trigger the
validationplan of the zookeeper operator which uses validation.yaml to create a Job. I can only see the plan status. This is okay but not helpful when I want to verify the template, see values of environment variables, or test any new operator locally. Having this option will be super helpful for debugging purposes. Of course, we can check the rendered templates by describing them or getting the logs. But having this feature will definitely prove to be productive in the overall dev and testing workflow.