Allow almost all printable ASCII characters in environment variables

[HirazawaUi]

Enhancement Description

• One-line enhancement description (can be used as a release note): Allow special characters in environment variables
• Kubernetes Enhancement Proposal: Allow almost all printable ASCII characters in environment variables #4373
• Discussion Link: Environment variables containing colon not allowed kubernetes#53201
• Primary contact (assignee): @HirazawaUi
• Responsible SIGs:
• Enhancement target (which target equals to which milestone):
  • Alpha release target (x.y): 1.30
  • Beta release target (x.y): 1.32
  • Stable release target (x.y): 1.33
• Alpha
  • KEP (k/enhancements) update PR(s):
    • Allow almost all printable ASCII characters in environment variables #4373
    • KEP-4396: promote kep into implementable #4482
  • Code (k/k) update PR(s):
    • Allow almost all printable ASCII characters in environment variables kubernetes#123385
    • KEP-4369: promote RelaxedEnvironmentVariableValidation feature gate to beta kubernetes#126897
  • Docs (k/website) update PR(s):
    • Document option to allow almost all printable ASCII characters in environment variables website#45125
    • Promote RelaxedEnvironmentVariableValidation to beta website#47663

Please keep this description up to date. This will help the Enhancement Team to track the evolution of the enhancement efficiently.

[kikisdeliveryservice]

@HirazawaUi Can you check and find out which sig will be owning this enhancement and update this issue.

[HirazawaUi]

@HirazawaUi Can you check and find out which sig will be owning this enhancement and update this issue.

I think it should be sig-node

[HirazawaUi]

/sig node
/sig api-machinery
/cc @liggitt @thockin

[thockin]

Agree sig-node

[tjons]

Hello @HirazawaUi 👋, Enhancements team here.

Just checking in as we approach enhancements freeze on Friday, February 9th, 2024 at 02:00 UTC.

This enhancement is targeting for stage alpha for 1.30 (correct me, if otherwise)

Here's where this enhancement currently stands:

• KEP readme using the latest template has been merged into the k/enhancements repo.
• KEP status is marked as implementable for latest-milestone: 1.30. KEPs targeting stable will need to be marked as implemented after code PRs are merged and the feature gates are removed.
• KEP readme has up-to-date graduation criteria
• KEP has a production readiness review that has been completed and merged into k/enhancements. (For more information on the PRR process, check here).

For this KEP, we would just need to complete the following:

• Merge the KEP readme into the k/enhancements repo.
• Complete the PRR review process and merge it into k/enhancements.
• Mark this KEP as implementable for latest-milestone: 1.30.

The status of this enhancement is marked as at risk for enhancement freeze. Please keep the issue description up-to-date with appropriate stages as well. Thank you!

[HirazawaUi]

The status of this enhancement is marked as at risk for enhancement freeze

I will try to finish it.

[thockin]

https://github.com/kubernetes/enhancements/pull/4478/files

[tjons]

@HirazawaUi everything looks good except I'm not sure that the KRR has final approval from @jpbetz - what is the status?

[tjons]

With all the requirements fulfilled this enhancement is now marked as tracked for the upcoming enhancements freeze 🚀

Actually, @HirazawaUi I was incorrect. This PR is also missing the v1.30 milestone in the Github issue. Therefore, unfortunately, this enhancement did not meet requirements for enhancements freeze.

If you still wish to progress this enhancement in 1.30, please file an exception request. Thanks!

[salehsedghpour]

/milestone clear

[HirazawaUi]

This PR is also missing the v1.30 milestone in the Github issue.

It's very sad.
I took a closer look at the exception description and realized that this enhancement doesn't seem to apply to it very well, and there's no reason we have to implement this enhancement in milestone 1.30, so I decided to move forward with it in 1.31.

[HirazawaUi]

/milestone v1.31

[k8s-ci-robot]

@HirazawaUi: You must be a member of the kubernetes/milestone-maintainers GitHub team to set the milestone. If you believe you should be able to issue the /milestone command, please contact your Milestone Maintainers Team and have them propose you as an additional delegate for this responsibility.

In response to this:

/milestone v1.31

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.

[thockin]

Hold up.

Release team, you know I love you all and your work is invaluable. But...why would we punish a contributor for something I screwed up? And for that matter, why do we need to set two independent indicators of intention, which literally mean the same thing?

I know we've got tons of enhancements in flight, but this is silly.

Edit with hindsight: This was not intended to be mean, but it came off that way, and I apologize. I am not deleting it because I am not hiding from my mistakes.

I did not want to seek an exception to the rules because I feared that it could be construed as abusing my tenure to get special treatment. I do think we can continue to streamline the process - we should aim to NOT do redundant bookkeeping, as much as possible, and I think that relying on exceptions is not ideal. But I could have said that a lot better.

[katcosgrove]

@thockin Please be kind to my team. They are contributors too, many of them first timers. Both myself and the enhancements lead have broad latitude to extend a little bit of grace in cases where there has clearly been a minor clerical error preventing an enhancement from being included in the release. You only need to ask for it. In this case, an exception would have been granted (you just have to send a short email), and either myself or @salehsedghpour would have approved the request without a formal exception request if contacted directly.

Shadows, who by their nature have little to no experience running any aspect of a release, do not have such latitude and must comply with the guidelines they have. Those guidelines are strict for a reason. As you said, we have quite a lot of enhancements in flight, and we have to minimize opportunities for confusion by making situations like this the exception rather than the rule. If you would like to see this policy changed, we're happy to discuss it at either the mid-cycle or post-cycle retro.

This enhancement is now considered tracked for v1.30.

/milestone v1.30

[thockin]

I didn't mean to be unkind, my apologies if it came off that way. "Clerical error" is the right formulation of this - thanks for that. The underlying problem - seemingly redundant information being required - has happened a few times, and it's never been clear how to make that go away (but it HAS gotten better, so credit where it's due). Process should serve humans, not vice-versa.

I somewhat dislike the idea of "direct contact" because I don't want it to be about who requested something, but I ACK that sometimes it just is. If possible, I'd be glad to brainstorm ways we could streamline the workflow, from both the POV of an "unreliable approver" and of an "earnest contributor", while still giving release-team the info you all need.

In this case it was clearly me who screwed up, but I am a screwup with a terrible memory.

I appreciate the response.

[katcosgrove]

It isn't about who requests something; it's about who can approve it. In a world where you instead chose to just reach out to me or the enhancements lead to note that this was kicked for a clerical error, who you are would not have been relevant to our decision to agree that it was clearly a clerical error. The KEP owner could have done it themself and the outcome would have been the same as if you asked me. Another enhancement owner did exactly that a couple of hours ago and was moved back to tracked without issue.

If you want to see this process improved, please attend the retros for this cycle, suggest an alternative, and take the action item.

[HirazawaUi]

Many thanks to @thockin and @katcosgrove for attention and help on this matter, If I could check in advance whether I need to send a full or mini "exception", then might be able to avoid this problem :-)

And after I read the documentation on exception, I was worried that a full 'exception' would bring an extra trouble to everyone, and I can't explain why this enhancement is crucial for this milestone, so I decided to push it in the next milestone.

Sorry for wasting your time focusing on this tiny issue, but thankfully things are back on track.

[Princesso]

Hello @HirazawaUi , 👋 1.30 Docs Shadow here.
Does this enhancement work planned for 1.30 require any new docs or modifications to existing docs?
If so, please follow the steps here to open a PR against the dev-1.30 branch in the k/website repo. This PR can be just a placeholder at this time and must be created before Thursday, February 22nd, 2024 18:00 PDT.
Also, take a look at Documenting for a release to get yourself familiarize with the docs requirement for the release.
Thank you!

[a-mccarthy]

Hi @HirazawaUi,

👋 from the v1.30 Communications Team! We'd love for you to opt in to write a feature blog about your enhancement!

We encourage blogs for features including, but not limited to: breaking changes, features and changes important to our users, and features that have been in progress for a long time and are graduating.

To opt in, you need to open a Feature Blog placeholder PR against the website repository.
The placeholder PR deadline is 27th February, 2024.
Here's the 1.30 Release Calendar

[tjons]

Hey again @HirazawaUi 👋 Enhancements team here,

Just checking in as we approach code freeze at 02:00 UTC Wednesday 6th March 2024 .

Here's where this enhancement currently stands:

• All PRs to the Kubernetes repo that are related to your enhancement are linked in the above issue description (for tracking purposes).
• All PR/s are ready to be merged (they have approved and lgtm labels applied) by the code freeze deadline. This includes tests.

For this enhancement, it looks like the following PR is open and needs to be merged before code freeze:

• Allow almost all printable ASCII characters in environment variables kubernetes#123385

Also, please let me know if there are other PRs in k/k we should be tracking for this KEP.
As always, we are here to help if any questions come up. Thanks!

[HirazawaUi]

Okay, I'll try to move it forward.

[Princesso]

Hello @HirazawaUi 👋 please take a look at Documenting for a release - PR Ready for Review to get your Docs PR ready for review before Tuesday March 12th 2024 18:00 PST. Thank you!

[HirazawaUi]

PR is already in review.

[Princesso]

Thank you, I'll have a look.

[tjons]

Hello @HirazawaUi 👋, Enhancements team here.

With all the implementation(code related) PRs merged as per the issue description:

• Allow almost all printable ASCII characters in environment variables kubernetes#123385

This enhancement is now marked as tracked for code freeze for the 1.30 Code Freeze!

[sreeram-venkitesh]

Hi @HirazawaUi 👋, 1.31 Enhancements Lead here.

If you wish to progress this enhancement in v1.31, please have the SIG lead opt-in your enhancement by adding the lead-opted-in label and set the milestone to v1.31 before the Production Readiness Review Freeze.

/remove-label lead-opted-in

[thockin]

@HirazawaUi Go Beta in 31?

[HirazawaUi]

@thockin I'd like to follow our previous plan of going into beta at v1.32 :)

[thockin]

OK. For what it's worth, almost nobody uses alpha's, so we're not gaining any information or safety by waiting. But if you are too busy to do the work, that's a decent excuse :)

[HirazawaUi]

But if you are too busy to do the work,

This is indeed one of the reasons 🥲.

[kannon92]

Moving this to consider for release for 1.32. Please let us know if you don't have capacity to take it. And if you don't feel free to ask if someone else would like to take it to beta.

[HirazawaUi]

Moving this to consider for release for 1.32. Please let us know if you don't have capacity to take it. And if you don't feel free to ask if someone else would like to take it to beta.

I will implement it this weekend :)

[thockin]

Is there a PR for this to move to beta?

[kannon92]

Yes. #4805