kubernetes / enhancements

Enhancements tracking repo for Kubernetes
Apache License 2.0
3.39k stars 1.46k forks source link

Allow almost all printable ASCII characters in environment variables #4369

Open HirazawaUi opened 8 months ago

HirazawaUi commented 8 months ago

Enhancement Description

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

kikisdeliveryservice commented 8 months ago

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

HirazawaUi commented 8 months ago

@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 commented 8 months ago

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

thockin commented 7 months ago

Agree sig-node

tjons commented 7 months ago

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:

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

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 commented 7 months ago

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

I will try to finish it.

thockin commented 7 months ago

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

tjons commented 7 months ago

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

tjons commented 7 months ago

~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 commented 7 months ago

/milestone clear

HirazawaUi commented 7 months ago

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 commented 7 months ago

/milestone v1.31

k8s-ci-robot commented 7 months ago

@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](https://github.com/kubernetes/enhancements/issues/4369#issuecomment-1935461670): >/milestone v1.31 Instructions for interacting with me using PR comments are available [here](https://git.k8s.io/community/contributors/guide/pull-requests.md). If you have questions or suggestions related to my behavior, please file an issue against the [kubernetes/test-infra](https://github.com/kubernetes/test-infra/issues/new?title=Prow%20issue:) repository.
thockin commented 7 months ago

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.

TPS_reports

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 commented 7 months ago

@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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 7 months ago

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 commented 6 months ago

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:

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

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 commented 6 months ago

Okay, I'll try to move it forward.

Princesso commented 6 months ago

Hello @HirazawaUi :wave: 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 commented 6 months ago

PR is already in review.

Princesso commented 6 months ago

Thank you, I'll have a look.

tjons commented 6 months ago

Hello @HirazawaUi πŸ‘‹, Enhancements team here.

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

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

sreeram-venkitesh commented 4 months ago

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 commented 4 months ago

@HirazawaUi Go Beta in 31?

HirazawaUi commented 3 months ago

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

thockin commented 3 months ago

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 commented 3 months ago

But if you are too busy to do the work,

This is indeed one of the reasons πŸ₯².

kannon92 commented 2 weeks ago

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 commented 2 weeks ago

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 commented 3 days ago

Is there a PR for this to move to beta?

kannon92 commented 3 days ago

Yes. https://github.com/kubernetes/enhancements/pull/4805