Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
Propose SIG-Platform-Dev charter. #2033
[APPROVALNOTIFIER] This PR is NOT APPROVED
This pull-request has been approved by:
Assign the PR to them by writing
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
Sorry I didn't wade in on this until now -- was on vacation last week.
My biggest question: why isn't client-go part of this SIG? That is the foundational piece of any SDK/PDK that we build. It is what all of the other potential sub projects are based on.
(Similarly, I think the rest of the language client libraries should be here too.)
If our goal is to get to the point where we have loose coupling between control plane components and we have flexibility around what makes up the control plane, then we need to have loose coupling for client-go. It will be painful but, IMO, is necessary to remove the "gatekeeper" nature of the k8s control plane as it exists today. (Having a loosely coupled client-go, for instance, is going to be critical for things like breaking out the cloud providers.)
If we don't include client-go then I'm not convinced that there is critical mass enough to support a SIG. The stuff that is left is ancillary and doesn't make up a PDK in any real way.
The out of scope section of the charter is our answer to this question. Can you point out the parts of that argument that you disagree with?
The scope section of the charter lays out the mass of work we think needs to be done.
We agree that all this work is ancillary to the Kubernetes project, in the sense that it "provides necessary support to the primary activities or operation of an organization or system".
Maintaining the Kubernetes API server and its first-party clients is a "primary activity" and lives in SIG-AM. Creating a development kit to help external consumers use those things (as well as controller machinery from sig-apps) is ancillary "support activity" that lives in SIG-PD, just like the Windows Driver Kit is ancillary to the Windows OS/Kernel.
I'm closing this PR because we've decided to start out by working on these issues within SIG API Machinery, at the recommendation of the steering committee. Please join the SIG-AM mailing list and meetings if you'd like to keep up with these efforts or contribute.
The new controller-oriented arm of SIG-AM has already begun to collaborate on several repos under the
Work has also begun on a cohesive set of docs specifically aimed at controller authors:
I still think this is not going to work. We had hardly AM meetings in the past where we had those discussions in the necessary depths. IMO this can have two reasons:
From discussion with 3rdparty developer about their pain using our libraries, the development of operator-framework+kubebuilder and the creation of those controler-runtime/tools repos suggests that there is more demand than is visible in AM.
Also I have never seen platform-dev topics on any AM roadmap.
So I am pretty sure it's the first of the two reasons. Do we agree that we keep it like that, i.e. under the radar? Or do we want to establish something (a working group? subgroup or whatever it is called) in addition?
Unfortunately, we couldn't convince the steering committee of that. So we're going to take their recommendation in good faith and do our best to build what we think our users need within the existing SIGs.
Agreed. Before this, we lacked consensus on where such topics should be discussed. Those of us working on controllers thought that SIG-AM was focused only on the interface aspects (IDL, REST client/server), and not on the implementation behind such interfaces (in the form of level-triggered, reconciling control loops).
The steering committee recommended expanding SIG API Machinery to encompass both, and I have proposed writing this into SIG-AM's future charter explicitly to clarify its new scope. The current mission statement doesn't mention anything about control loops.
We plan to increase visibility of controller topics in SIG-AM by showing up to SIG meetings, giving updates on our subprojects, using the SIG mailing list for discussion, and so on. I propose that we see how that goes for a bit and then discuss at a future SIG-AM meeting whether we need more structure.
Hi there, I just want to express my sadness as I have been waiting for this SIG to eventually form. Not only because I agree with the others that this was good idea. But also because I wanted to offer my help and work with the others to make developers life easier especially the ones that intend to extend and consume Kubernetes APIs.