/sig cli

/label lead-opted-in
/milestone v1.30

/stage alpha

/assign @ardaguclu

Hello @ardaguclu 👋, 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:

• Add graduation criteria to the KEP readme.
• Merge the KEP readme into k/enhancements.
• Complete the PRR review process and merge it into k/enhancements.

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!

@tjons thanks for checking the KEP. But I have added graduation criteria as you can see in https://github.com/kubernetes/enhancements/pull/4293/files#diff-708a3d9c4718ca7f3da37b08c6cbee5ff7fc7df4f496783dd213b7abf0f2c216R98, do you mean adding somewhere else?.

@ardaguclu whoops, missed that in the diff! thanks for updating me. I've updated my commend accordingly.

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

Hi @ardaguclu,

👋 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

Hello @ardaguclu 👋, v1.30 Docs Shadow here.

Does this enhancement work planned for v1.30 require any new docs or modification to existing docs?

If so, please follows the steps here to open a PR against 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!

Does this enhancement work planned for v1.30 require any new docs or modification to existing docs?

Going through the changes this PR entails, we'll need a docs PR. Marking this as Need Docs. Thanks for this cool feature!

Hey again @ardaguclu 👋 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 PRs are open and need to be merged before code freeze:

• kubectl debug: Add custom debug profiles on top of static profiles kubernetes#120346

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!

Hello @ardaguclu 👋, Enhancements team here.

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

• kubectl debug: Add custom debug profiles on top of static profiles kubernetes#120346

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

This feature makes the kubectl debug command actually useful to me, so thank you for it. My team has always been somewhat turned-off from building their applications in shell-less base images because it was really annoying and difficult to runtime debug those containers, so being able to mount data volumes and such in the debug container will be a huge security win for us, I think. Couple of suggestions but I can't overstate how I'm already happy with the current state of it:

• It'd be nice if the file pointed to with the --custom flag could also be yaml (I'm somewhat assuming it can't be based on the docs specifying json.)

• It also might be nice if I could just put raw json into the flag, rather than making a local file for it. But I can work around this with a small bash wrapper function I think that just makes the file and cleans it up afterward. I have a habit of leaving random files around my home directory that I have to clean up later.

Since both of those feature suggestions kind of clash in usage, it might make more sense to consider doing one (if not neither) of them. The raw json in the flag idea is mostly just how I imagined the flag worked before I tried it. The yaml idea might be more generally useful to other people.

This is actually my first time replying to a KEP issue here so let me know if there is anything else I can provide to the team here.