SIG Network: add best practices guide for API extensions #8104
Conversation
|
Skipping CI for Draft Pull Request. |
k8s-ci-robot
added
do-not-merge/work-in-progress
|
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: shaneutt The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
k8s-ci-robot
added
approved
shaneutt
changed the title
| [geps]:https://github.com/kubernetes-sigs/gateway-api/blob/main/geps/overview.md | ||
| [npeps]:https://github.com/kubernetes-sigs/network-policy-api/tree/main/npeps | ||
|
|
||
| #### Motivation Focused Enhancement Proposals |
There was a problem hiding this comment.
This applies to KEPs too. And "new working group" proposals...
There was a problem hiding this comment.
Yes indeed. 👍
What action do you want to see taken here?
shaneutt
force-pushed
the
shaneutt/sig-network-api-extensions-best-practices
branch
from
7e0144f
to
b3ba9d7
Compare
| current sub-projects: | ||
|
|
||
| * [Gateway Enhancement Proposals (GEPs)][geps] | ||
| * [Network Policy Enhancement Proposals (NPEPs)][npeps] |
There was a problem hiding this comment.
Cluster API, while under a different sig, also has similar problems I think. They use CAEPs. If you want to expand the scope of this beyond network at some point, might be good to include as an example
There was a problem hiding this comment.
Yes, making this more broad is definitely on the table. Making SIG Network the starting point and scope limit for the first iteration is mostly about wanting to get something out there quicker at the networking scope to help our upcoming multi-networking efforts, and potentially other projects like KNI.
| > (version is v1 or greater) with a `*.k8s.io` group **MUST** go through the API | ||
| > review process with the SIG Network leads for any content considered |
There was a problem hiding this comment.
Is it just sig network that review the API graduation? I was under the impression K8s had a set of API reviewers responsible for this, sig-api-machinery folks maybe?
There was a problem hiding this comment.
there is a set of people that holds the API reviewer "title", but independently , SIGs TLs are responsible of the technical side of the area https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance.md#tech-lead
|
/hold after more closely reviewed on this topic it is clear that there are still a lot of details to flesh out on gateway design of CRD |
k8s-ci-robot
added
the
do-not-merge/hold
Signed-off-by: Shane Utt <shaneutt@linux.com>
shaneutt
force-pushed
the
shaneutt/sig-network-api-extensions-best-practices
branch
from
1bae0c1
to
a16cfd0
Compare
This PR is a follow up to a mailing list discussion about the trend of new APIs being developed as CRDs in upstream.
This adds a guide to our community pages which provides help, insights and best practices for future CRD-based API developments based on the experiences of those who have done it previously (like Network Policy and Gateway API). The intention is to help make developing these CRD-based APIs easier for developers, but (most importantly) making the experience for end-users easier, and more consistent.