Production readiness policy lazy consensus

114 views
Skip to first unread message

John Belamaric

unread,
Dec 15, 2020, 5:34:17 PM12/15/20
to Kubernetes developer/contributor discussion
Hello Kubernetes Developers,

For the last few releases, KEP authors have been including Production Readiness responses in their KEPs. Through 1.20, filling out these sections was required, but PRR approval was not.  Now the time has come, with 1.21, to require PRR approval for a KEP to be targeted to the release.

This is implemented in the following PRs, which are held for lazy consensus until Monday, December 21st at noon Pacific standard time.


The last PR requires that a few KEPs that had already set their `latest-milestone` to 1.21 be updated. Those will need PRR approval prior to the Enhancements Freeze for 1.21 (date TBD), like all other KEPs. Because of how the tooling works, we had to tweak the `latest-milestone`. We will tag the KEP authors on that PR directly.

Thank you,
Prod Readiness Team

ehas...@redhat.com

unread,
Jan 4, 2021, 5:14:32 PMJan 4
to Kubernetes developer/contributor discussion
Hi John and the Prod Readiness Team!

Thanks so much for your hard work on this. I totally missed this email during the transition into the holiday period. Today I noticed that this criteria is now gating KEPs for 1.21+ as part of CI.

The KEP is pretty sparse for info on what next steps for leads/authors/etc. are: https://github.com/kubernetes/enhancements/tree/master/keps/sig-architecture/1194-prod-readiness#phase-2---implementation

Quoting,

The process will be enforced in the enhancements repository. A separate prod-readiness directory will be maintained, with an OWNERS file with PRR-specific reviewers and approvers.

I see there is a keps/prod-readiness directory that's been created, and the OWNERS file with prod-readiness-approvers was populated with just three people: https://github.com/kubernetes/enhancements/blob/243db9d8a262b477d722e0e47129663f7c4173d3/OWNERS_ALIASES#L184-L187

This seems like it will add a large bottleneck to the KEP process. I am a bit uncomfortable with gating every KEP on three individuals without wider project discussion. I'm not convinced we've actually reached lazy consensus as many individuals I've reached out to when asking about this change were completely unaware of it; can we put this on hold until the community's had more of a chance to review? It would be great if we could add this to the agenda for the next leads discussion, as it was not covered in the December meeting (or earlier afaik).

- e

John Belamaric

unread,
Jan 5, 2021, 7:12:52 PMJan 5
to ehas...@redhat.com, Kubernetes developer/contributor discussion
Hi,

That seems like a reasonable request. We certainly didn't want it to go in without review. I don't expect a big bottleneck, because the policy only applies specifically when a KEP targets a release. But for now, we could relax the validation that enforces it, until we have some further discussion and everyone is OK with it. I still hope to target the 1.21 release with this change, though, so discussion will need to happen ASAP.

John


--
You received this message because you are subscribed to the Google Groups "Kubernetes developer/contributor discussion" group.
To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/85b67399-efda-4c5d-ad65-3ecf5cf91ab7n%40googlegroups.com.

Elana Hashman

unread,
Jan 5, 2021, 7:29:17 PMJan 5
to John Belamaric, Kubernetes developer/contributor discussion
Thanks John!

Let's add this to the agendas of the monthly leads meetings next week?

- e
Reply all
Reply to author
Forward
0 new messages