KEP2149: Add the well known property ladder #5255
Conversation
k8s-ci-robot
added
cncf-cla: yes
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: ryanzhang-oss The full list of commands accepted by this bot can be found here.
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
sig/multicluster
|
Hi @ryanzhang-oss. Thanks for your PR. I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with Once the patch is verified, the new status will be reflected by the I understand the commands that are listed here. 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-sigs/prow repository. |
k8s-ci-robot
added
the
size/S
| * The property sponsor must present a discussion agenda with clear use cases and motivation at a Multi-cluster SIG meeting. | ||
| * The community will vote on the proposal, and if it receives approval from at least 2/3 of voters, the property becomes a standard property and is incorporated into the About API KEP. | ||
|
|
||
| 3. **Core Property Stage**: After a property has maintained standard status for at least 3 months and has 3 or more implementations, one can propose to elevate it to a **core** property which means it must be implemented by every implementer that implements the About API. |
There was a problem hiding this comment.
what happens if it is missing? 3months from? given we don't have a release process so it may be hard to start counting?
Should we have some kind of versioning in place?
If we don't have versioning, we may want more than 3mo of stability.
| 2. **Standard Property Stage**: The implementor can propose to add a property to be a **standard** property which means if anyone implements the property with the same name, it must follow the same definition and rules described in the KEP. Not all implementers are required to implement the property. | ||
| The process for proposing a standard property is as follows: | ||
| * The property sponsor must present a discussion agenda with clear use cases and motivation at a Multi-cluster SIG meeting. | ||
| * The community will vote on the proposal, and if it receives approval from at least 2/3 of voters, the property becomes a standard property and is incorporated into the About API KEP. |
There was a problem hiding this comment.
How are people eligible to vote? Do we need a quorum? Is there a cool off period between votes on similar proposals? Is there any veto powers by the sig co chairs? Is there anything from CNCF or other SIGs we can, must, or even want to draw on for regulations or tooling?
What, if any, are the obligations of the About API subproject or the proposer to facilitate implementation of a new standard property? For example do we ship the About API with as much webhook coverage as possible for the validation? Do we publish and/or run periodic About API conformance tests for standard properties, or only core properties, or none? If by conformance tests or otherwise we want to try to enforce compliance, how do we determine which implementations to "watch"?
|
|
||
| We foresee that there will be more properties that the community wants to adopt as "well known" properties. Thus, we want to define a process for adopting a property to be a well known property in the future: | ||
|
|
||
| 1. **Extension Property Stage**: A property is implemented as an extension property if the implementer has no intent to elevate it to a standard property. This property cannot use the reserved suffixes and is not required to be implemented by all implementers. |
There was a problem hiding this comment.
I think "Extension Property" and "Additional Property" (in the directly preceding header and section) are referring to the same definition. Can we pick one term? Either is fine with me
|
|
||
| 2. **Standard Property Stage**: The implementor can propose to add a property to be a **standard** property which means if anyone implements the property with the same name, it must follow the same definition and rules described in the KEP. Not all implementers are required to implement the property. | ||
| The process for proposing a standard property is as follows: | ||
| * The property sponsor must present a discussion agenda with clear use cases and motivation at a Multi-cluster SIG meeting. |
There was a problem hiding this comment.
I think we can add in the template they need to follow too, drawing from the existing ones like
The requirements below use the keywords **must, should,** and **may**
purposefully in accordance with [RFC-2119](https://tools.ietf.org/html/rfc2119).
#### Property: `[INSERT PROPERTY NAME HERE]`
##### Uniqueness
##### Lifespan
##### Contents
##### Consumers
##### Uniqueness
##### Notable scenarios (optional)
Maybe we also want to add in that a head for the use cases need to be included inline, and we update the ones we have today with that too.
Add the well known property ladder