/sig windows
/milestone v1.15

Hey, @PatrickLang 👋 I'm the v1.15 docs Lead.
Does this enhancement require any new docs (or modifications)?

Just a friendly reminder we're looking for a PR against k/website (branch dev-1.15) due by Thursday, May 30th. It would be great if it's the start of the full documentation, but even a placeholder PR is acceptable. Let me know if you have any questions

Hi @PatrickLang, today is code freeze for the 1.15 release cycle. The k/k PRs kubernetes/kubernetes#73609 has not yet been merged. It's now being marked as At Risk in the 1.15 Enhancement Tracking Sheet. Is there a high confidence this will be merged by EOD PST today? After this point, only release-blocking issues and PRs will be allowed in the milestone with an exception.

/milestone clear

/milestone v1.16

Hi @PatrickLang , I'm a 1.16 Enhancement Shadow. Is this feature going to be graduating to alpha stage in 1.16? Please let me know so it can be added to the 1.16 Tracking Spreadsheet. If not's graduating, I will remove it from the milestone and change the tracked label.

If there are any other PRs besides kubernetes/kubernetes#73609, please list all relevant k/k PRs in this issue so they can be tracked properly.

Milestone dates are Enhancement Freeze 7/30 and Code Freeze 8/29.

Thank you.

hi @evilgenius75 - it's merged in kubernetes/kubernetes#79489 :)
/close

@PatrickLang: Closing this issue.

@PatrickLang we need to keep this open until the feature has graduated to stable. Is there any other reason why it should be closed?

Hey @PatrickLang

I'm one of the v1.16 docs shadows.
Does this enhancement (or the work planned for v1.16) require any new docs (or modifications to existing docs)? If not, can you please update the 1.16 Enhancement Tracker Sheet (or let me know and I’ll do so)

If so, just a friendly reminder we're looking for a PR against k/website (branch dev-1.16) due by Friday, August 23rd, it can just be a placeholder PR at this time. Let me know if you have any questions!

doc PR: kubernetes/website#15378

test PR: kubernetes/kubernetes#79539

@PatrickLang code freeze for 1.16 is on Thursday 8/29. Are there any outstanding k/k PRs that still need to be merged for this to go Alpha? Looks like only thing we're waiting on is kubernetes/kubernetes#79539 to be merged.

Hello @PatrickLang ,

I'm 1.18 docs shadow.

Just want to know if this enhancement work planned for 1.18 require any new docs (or modifications to existing docs)? If not, can you please update the 1.18 Enhancement Tracker Sheet (or let me know and I'll do so)

If so, just a friendly reminder we're looking for a PR against k/website (branch dev-1.18) due by Friday, Feb 28th, it can just be a placeholder PR at this time. Let me know if you have any questions!

Warm regards,

chima

@iheanyi1 - have doc PR attached. code PRs are merged.

/milestone v1.18

Hi @PatrickLang We're only a few days out from code freeze now. It does not look like your PR has merged yet, are you still feeling like you're on track for code freeze for this enhancement? Do you want to defer this to 1.19 based on the reviewer bandwidth? Or try and make a push?

@helayoty we want to try and get this in for 1.18 since the code PRs already merged.
I DM'd @tengqm on slack to take a look since this just needs approval from sig-docs-en-owners

All PRs merged. Thanks for all the hard work everyone!

/stage stable

Hi @PatrickLang, since this enhancement graduated to stable in 1.18, can you please mark the KEP as implemented?

/reopen
(reopening the issue until the KEP is marked implemented)

@palnabarun: Reopened this issue.

@palnabarun I can update the KEP.

@marosset Thank you 🙂

The KEP covers more than than just the RunAsUserName feature/API work - I think everything in the KEP has been implemented but am checked with @ddebroy

All aspects of the KEP (including RunAsUserName and GMSA credspecs) has indeed been implemented and graduated to stable. So I went ahead and marked the KEP implemented in #1743

As @marosset correctly pointed out above, the KEP covers the overall windowsOptions in securityContext in pod specs. We wrote that KEP to drive the API discussion and reviews around windowsOptions - which is a broader topic than runAsUserName that is the focus of this issue. GMSA had it's own dedicated KEP (since there was quite a lot of details to clarify there) but a dedicated KEP for runAsUserName was considered unnecessary as the concept was already well understood from the perspective of API reviews.

Thank you @marosset @ddebroy for updating the status of the KEP. 👍

/close

(since the corresponding KEP has been implemented)

@palnabarun: Closing this issue.