CRI API development policies #49455
CRI API development policies #49455
Conversation
k8s-ci-robot
added
sig/node
|
[APPROVALNOTIFIER] This PR is NOT APPROVED This pull-request has been approved by: 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
the
size/L
✅ Pull request preview available for checkingBuilt without sensitive environment variables
To edit notification comments on pull requests, go to your Netlify site configuration. |
| @@ -6,6 +6,8 @@ no_list: true | |||
|
|
|||
| This section contains the following reference topics about nodes: | |||
|
|
|||
| * Policies on [Kubernetes feature development and Container runtimes](content/en/docs/reference/node/cri-api-development-policies.md) | |||
There was a problem hiding this comment.
The link will need correction.
| * Policies on [Kubernetes feature development and Container runtimes](content/en/docs/reference/node/cri-api-development-policies.md) | |
| * Policies on [Kubernetes feature development and Container runtimes](/docs/reference/node/cri-api-development-policies) |
There was a problem hiding this comment.
/hold
Looking at this change, I think it's in the wrong Git repository and would publish to the wrong place. It's OK to publish this policy to https://k8s.dev/ and then have https://kubernetes.io/docs/ hyperlink to that new policy page.
OK to unhold if SIG Docs tech leadership confirms that this repo is the right home.
There was a problem hiding this comment.
Does this document belong within https://k8s.dev/docs/?
If not, https://kubernetes.io/docs/reference/using-api/deprecation-policy/ should change (maybe with a new URL, and a redirect from its old home) to link to this new document.
| ## Same maturity level (for beta and GA) | ||
|
|
||
| Implementation of an API needed for a Kubernetes feature in a container runtime | ||
| MUST be at least the same maturity as in k8s at a moment of Kubernetes release. |
There was a problem hiding this comment.
use bold for emphasis; avoid using un-bolded ALL CAPS to achieve the same thing.
Also, avoid the abbreviation “k8s” (especially all lowercase) within reference pages, unless the API or whatever specifically uses the abbreviation.
| Features and CRI API are supposed to be portable and generic and not limited to | ||
| a specific container runtime. However at this moment we require every feature to | ||
| work on two container runtimes: [Containerd](https://containerd.io/) and | ||
| [CRI-O](https://cri-o.io/). These are two runtimes that are tested as part of a | ||
| kubernetes development and release process. When this document refers to two | ||
| container runtimes, it assumes both - Containerd and CRI-O. If any other | ||
| container runtimes begin working actively with the Kubernetes community, this | ||
| document will need to be updated. |
There was a problem hiding this comment.
This sounds like details aimed at contributors, not end users.
Also also, avoid using “we“
| experience for people trying the new feature early, adopting it when it is | ||
| enabled by default, and relying on it as a GA functionality. | ||
|
|
||
| ## Supported container runtimes |
There was a problem hiding this comment.
We cannot risk implying that runtimes not on this list are unsupported. I think we must change this text.
I think this is a list of runtimes that this project uses for its own release testing. It's not related to conformance, for example.
| The mechanics of a feature development that requires new CRI APIs is covered in | ||
| documentation on CRI API [feature-development](https://github.com/kubernetes/cri-api?tab=readme-ov-file#feature-development). |
There was a problem hiding this comment.
In end user docs we avoid hyperlinking to pages on GitHub, especially anything in-project.
| --- | ||
| content_type: "reference" | ||
| title: Kubernetes feature development and Container runtimes | ||
| weight: 10 |
There was a problem hiding this comment.
(nit) should be a larger number, ie lower priority
| Both Containerd and CRI-O MUST have a GA release with the implementations of an | ||
| API needed for a Kubernetes feature before this Kubernetes feature can be | ||
| promoted to GA. |
There was a problem hiding this comment.
Avoid making this sound like a commitment. Imagine if the containerd project closed and everyone used to a rival thing (Docker maybe?)
We would still release Kubernetes and wouldn't require eg a bump to major version 2 to bypass this. It's not a commitment.
k8s-ci-robot
added
the
do-not-merge/hold
|
Just to be clear, I've no disagreement with the policy as drafted; my concern is about where we publish it We should make an implication that "must work with CRI-O and containerd" is part of conformance if and only if we're sure that's the message we're stating publicly. |
Description
Policies of CRI API development.
The consensus was recieved via google doc: https://docs.google.com/document/d/1y42XrUPrm-6DZby1RQjexYYoNn822IRR6igsOiy_62c/edit?tab=t.0#heading=h.nzjfadot7nt7 and presented on both - SIG Node and SIG Atchitecture.
I am following the example of https://kubernetes.io/docs/reference/using-api/deprecation-policy/ placing it under the "Reference" section of docs.
/sig node