Env var expansion guidelines

[msau42]

Is this a BUG REPORT or FEATURE REQUEST?:
@kubernetes/sig-node-feature-requests

What happened:
Before moving kubernetes/enhancements#559 to beta, we should have some further discussions about env expansion in general. Specifically:

• Are there better ways to implement this? Right now, each case of env expansion is handled independently at different points, and revalidation is considered specifically for each case. Is a general/common solution feasible?
• If not, can we identify some standard/criteria for what fields should be allowed for expansion, and how they should handle revalidation.

[msau42]

cc @kevtaylor

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[msau42]

/remove-lifecycle stale

[thockin]

I don't think there is a general solution to revalidation, and there isn't a generic "do expansions" hook in the lifecycle. Can you be more concrete in what you're proposing? I'd love to be more rigourous here, if we can...

[msau42]

I wasn't proposing anything, just wanted to explore if there was a more general way we could do field expansion and not special-case each field. After the last few discussions, I've come to the conclusion that a general in-place expansion mechanism is not feasible due to:

1. Breaking API compatibility
2. Timing challenges of revalidation of the fields after expansion

[thockin]

We can establish precedent for "so you want to add env expansion to an existing field" (but only for optional fields). I don't think we can have a truly generic mechanism for the rest

…

On Thu, Aug 23, 2018 at 11:13 AM Michelle Au ***@***.***> wrote: I wasn't proposing anything, just wanted to explore if there was a more general way we could do field expansion and not special-case each field. After the last few discussions, I've come to the conclusion that a general in-place expansion mechanism is not feasible due to: Breaking API compatibility Timing challenges of revalidation of the fields after expansion — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.