Supported mechanism for setting ytt experiments for ytt template step

[pivotaljohn]

Describe the problem/challenge you have I want an end-user to easily be able to configure a template tool (for me, it's ytt) via an environment variable (in this case, to enable experimental feature(s) within the tool).

Describe the solution you'd like In my particular circumstance, the target users are those who have a significant amount of experience/familiarity with the Carvel tools; so, we're not requesting a special API for this, per se. It's also understandable/acceptable that this would be a namespace-wide setting. 👍🏻

@vrabbi had suggested in the May 12, 2022 Community Meeting that patching the Deployment that is the kapp-controller process in the standard way (i.e. spec.template.spec.containers[].env).

Anything else you would like to add: I haven't thought about other use-cases where this kind of configuration is desired for individual tools (and even individual App CRs). If supporting that is more appropriate, it would also fit this use-case.

---

Vote on this request

This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.

👍 "I would like to see this addressed as soon as possible" 👎 "There are other more important things to focus on right now"

We are also happy to receive and review Pull Requests if you want to help working on this issue.

[cppforlife]

changed title to very specific thing (ytt expirements) since there is no concept of env vars in templating steps (there is no guarantee that they are binary executions even though thats how all of them are implemented today).

@vrabbi had suggested in the May 12, 2022 Community Meeting that patching the Deployment that is the kapp-controller process in the standard way (i.e. spec.template.spec.containers[].env).

i do like this option as a way to experiment for folks, since i assume it's not our intent to encourage people to use ytt experiments in production environments?

[joe-kimmel-vmw]

It sounds like if we want this available globally, someone could add the environment variable to the kc deployment via an overlay, so the only work to do would be advertising/documenting this capability?

@pivotaljohn are there arguments to be made against having the flag on globally? - would it ever break existing features/behavior? Do we expect that features under "experimental" will make their way into "regular" at some point?

Another option in terms of making it easy to make it available only for selected AppCR would be if ytt took a --experimental=enabled flag on the command line.

[pivotaljohn]

@joe-kimmel-vmw asked:

... are there arguments to be made against having the flag on globally? - would it ever break existing features/behavior? Do we expect that features under "experimental" will make their way into "regular" at some point?

"Experimental" means NOT production or any system that has any requirement for stability, reliability, security, etc.

I imagine someone will come along with a multi-tenant-related use case... but I'd discourage use outside of anything except POCs, personal use, etc.

[neil-hickey]

I imagine someone will come along with a multi-tenant-related use case... but I'd discourage use outside of anything except POCs, personal use, etc.

If that's the case, I think it's more realistic to assume this is just a global setting on KC through the deployment env variables.

Allowing individual AppCRs to enable it seems unnecessary. Maybe we close this out with the suggestion of using the deployment environment variables?

@pivotaljohn / @joe-kimmel-vmw

[github-actions[bot]]

This issue is being marked as stale due to a long period of inactivity and will be closed in 5 days if there is no response.