New SIG Proposal: Platform Dev

[Jimmy Zelinskie]

Mission Statement

A Special Interest Group focused on toolkits for developers who extend the Kubernetes platform by writing command line tools and API extensions such as operators.

Proposed Name

SIG-Platform-Dev, indicating that the SIG supports developers who extend the Kubernetes platform.

Secondary Statement

This SIG will focus on the tooling used to build, run, upgrade, and maintain API extensions to Kubernetes and will drive direct feedback on the core primitives used for extension that are maintained by SIG API Machinery.

Purpose

Most developers are familiar with the term “operators”, but this concept has yet to have organization and consensus in upstream development of Kubernetes. There now exists a fractured ecosystem of Kubernetes feature extensions, especially as productized distributions of Kubernetes continue to differentiate from upstream. Similarly, there are many distinct but overlapping tools and resources aimed at helping people create such extensions. This SIG will serve as the centralized point for discussion and development of subprojects in order to better understand users’ intentions to extend Kubernetes and collaborate on a cohesive set of tools to help them do so.

Relation to Existing SIGs

• SIG-Apps will continue to own generic (apps/v1) controllers. SIG-Apps will continue to be the first place that K8s users go to discuss running applications on Kubernetes. Discussion of use of generic (apps/v1) controllers and the operator pattern would continue to occur in SIG-Apps.  Deeper discussion of operator development tools, such as SDKs, would happen in this SIG. Apps and this SIG would jointly work on how operator generation tools will embody best practices for running Apps on Kubernetes.

• SIG-API Machinery would continue to own the code in API server. API Machinery and this SIG would collaborate on changes to the API extension APIs (e.g. apiextension API group).  Responsibility for code generation and client generation initially remains part of API machinery, but might transition to this SIG with the advice and consent of API Machinery.

• SIG-CLI would continue to own code in kubectl.  Members of this SIG would likely contribute changes and test code to kubectl to ensure support for CRDs, and for other artifacts generated by this SIG's tooling.  

• The proposed Developer Tools Working Group would have application developers as an audience (people who write services that run on K8s).  This is quite a different audience than "platform developers" who write extensions to Kubernetes.  So, minimal overlap here.

Potential Subprojects

• github.com/kubernetes-sigs/kubebuilder

• github.com/GoogleCloudPlatform/metacontroller

• github.com/coreos/ALM (to be open sourced)

Implementation

The SIG will meet via Zoom bi-weekly for demos, scheduled discussions, and product planning.

First meeting will be a face to face meeting at KubeCon EU.

Potential Initial Chairs

Jimmy Zelinskie (Red Hat)

Phillip Wittrock (Google)

Anthony Yeh (Google)

[Michael Hausenblas]

As someone who actively develops tooling that falls into the “extend
the platform” category I welcome and support this new SIG and will, if
accepted, participate.

Cheers,
Michael

--
Michael Hausenblas
Ireland, Europe
http://mhausenblas.info/

> -

>
> SIG-Apps will continue to own generic (apps/v1) controllers. SIG-Apps
> will continue to be the first place that K8s users go to discuss running
> applications on Kubernetes. Discussion of use of generic (apps/v1)
> controllers and the operator pattern would continue to occur in SIG-Apps.
> Deeper discussion of operator development tools, such as SDKs, would
> happen in this SIG. Apps and this SIG would jointly work on how operator
> generation tools will embody best practices for running Apps on Kubernetes.

> -

>
> SIG-API Machinery would continue to own the code in API server. API
> Machinery and this SIG would collaborate on changes to the API extension
> APIs (e.g. apiextension API group). Responsibility for code generation and
> client generation initially remains part of API machinery, but might
> transition to this SIG with the advice and consent of API Machinery.

> -

>
> SIG-CLI would continue to own code in kubectl. Members of this SIG
> would likely contribute changes and test code to kubectl to ensure support
> for CRDs, and for other artifacts generated by this SIG's tooling.

> -

>
> The proposed Developer Tools Working Group would have application
> developers as an audience (people who write services that run on K8s).
> This is quite a different audience than "platform developers" who write
> extensions to Kubernetes. So, minimal overlap here.
>
>
> Potential Subprojects
>

> -
>
> github.com/kubernetes-sigs/kubebuilder
> -
>
> github.com/GoogleCloudPlatform/metacontroller
> -

>
> github.com/coreos/ALM (to be open sourced)
>
>
> Implementation
>
> The SIG will meet via Zoom bi-weekly for demos, scheduled discussions, and
> product planning.
>
> First meeting will be a face to face meeting at KubeCon EU.
>
> Potential Initial Chairs
>
> Jimmy Zelinskie (Red Hat)
>
> Phillip Wittrock (Google)
>
> Anthony Yeh (Google)
>

> --
> 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 post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/6d196ba8-657b-4267-b332-94c30376b338%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
>

[Harry Zhang]

It's great to have this sig~

[Michael]

Great initiative!

[Stefan Schimanski]

As discussed many times before, SIG-API-Machinery is overloaded with too many topics and platform dev does not get the necessary attention there. So having a separate forum for these topics would be great. I am happy to participate if this proposal is accepted.

I am unsure about the proposed split between API-Machinery and Platform-dev for the low-level tools, i.e. about the repos k8s.io/{apiserver,code-generation,apiextensions-apiserver}. They are hard to split from the API machinery discussions and responsibilities. Tight collaboration is great, but a move of responsibility to a new sig feels wrong at this point.

Having said this, I would like to see more active collaboration between those working on low-level API machinery tooling and those consuming (and wrapping) it one layer higher (this SIG). The proposed initial chairs suggest that we do not bridge this gap between the two groups by creating SIG-Platform-Dev. Having a overlap in people would make this collaboration much easier. 

Best regards,

   Stefan

--

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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

[pjp...@gmail.com]

+1 Stefan's remarks.

Best regards,

   Stefan

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.

[Vladimir Vivien]

This sounds like a great initiative.  Looking forward to it.

[Klaus Ma]

Really great initiative!!

Hmm.... will a Working Group be better? This work will cross multi SIGs; also includes scheduling (Bobby has a proposal to make default scheduler as a framework) and/or node (new CRI or device plugin implementation).

[Clayton Coleman]

I think the desire was to have something permanently focused on platform extension, because there is no future for a non-extension friendly Kubernetes.  I believe this  group would own code and sub projects that are aligned with the Kubernetes mission that would probably not be appropriate for sig-api-machinery to have to own.

--

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 post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/6a08566e-c212-48ae-8d59-a0716dee7480%40googlegroups.com.

[Brian Grant]

I agree that collaboration between the groups will be necessary. I don't think the chairs of each group need to be constantly involved in the other, and they likely don't have bandwidth.

I agree about the low-level code. 

There was a prior discussion about a client library SIG. I didn't think that would have critical mass. I think this broader scope could. 

During the discussions about homes for operatorkit, kubebuilder, and metacontroller, it became evident that each alone was hard to fit into existing groups.

K8s is a platform for building things on top. We need SDKs for building clients and server-side components. We need people focused on building them.

We could add a significant number of subproject to API Machinery, but that SIG has it's hands full with 2 API extension mechanisms, admission extensions, store evolution, and improvement of core machinery along at least half a dozen dimensions.

A WG is not appropriate, as these projects will continue indefinitely, and the code needs a permanent home.

Best regards,

   Stefan

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/6d196ba8-657b-4267-b332-94c30376b338%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAFtQ%3DdrjyALVn-%3DuNH1aR1EZJfxaCNjY%2Bov4Xk70ncxETKSuFw%40mail.gmail.com.

[Joseph Jacks]

I’m in favor of this SIG. There is quite a lot of fragmentation in the ways people are implementing extensions to the K8s API for satisfying operator patterns and others. The intersection with related SIGs was helpful and I tend to agree that sufficient disorganization and activity exists in this area to justify its own SIG.

[Joe Beda]

I'm going to buck the trend here and say that I'm skeptical of adding a new SIG around this topic.

Is there a reason that these things cannot be sub-projects of SIG-API-Machinery?  I'd *love* to see that SIG get more customer focused vs. just building infrastructure.

The one exception I'd say here is if this new SIG were going to take on client-go and really make that work for folks outside of the Kubernetes project itself.  It is a known pain point that, in my opinion, deserves attention. It is by far the top priority.  Without taking on client-go this SIG is just a place for a set of projects that perhaps should be associated projects and not Kubernetes projects itself.

The two sub projects that I can look at -- (What is ALM? Any details? Where has this been discussed?) seem to be on the bubble for in scope for Kubernetes at all.  I love things like metacontroller but how is that any different from other projects that build on top of Kubernetes and make it easier to work with?  How do we separate that from the raft of FaaS services?

I'd like to take this discussion to the Steering Committee before we move forward with a new SIG here.

Joe

--

[Clayton Coleman]

On Apr 3, 2018, at 11:46 AM, Joe Beda <j...@heptio.com> wrote:

I'm going to buck the trend here and say that I'm skeptical of adding a new SIG around this topic.

Is there a reason that these things cannot be sub-projects of SIG-API-Machinery?  I'd *love* to see that SIG get more customer focused vs. just building infrastructure.

The one exception I'd say here is if this new SIG were going to take on client-go and really make that work for folks outside of the Kubernetes project itself.  It is a known pain point that, in my opinion, deserves attention. It is by far the top priority.  Without taking on client-go this SIG is just a place for a set of projects that perhaps should be associated projects and not Kubernetes projects itself.

The two sub projects that I can look at -- (What is ALM? Any details? Where has this been discussed?) seem to be on the bubble for in scope for Kubernetes at all.  I love things like metacontroller but how is that any different from other projects that build on top of Kubernetes and make it easier to work with?  How do we separate that from the raft of FaaS services?

I'd like to take this discussion to the Steering Committee before we move forward with a new SIG here.

Wouldn’t those questions be more sig-architecture?

You received this message because you are subscribed to the Google Groups "steering" group.
To unsubscribe from this group and stop receiving emails from it, send an email to steering+u...@kubernetes.io.
To post to this group, send email to stee...@kubernetes.io.
Visit this group at https://groups.google.com/a/kubernetes.io/group/steering/.
To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAEAFPYJOkz31Lxx660o7M%3DNw_ssJ1OpVUn%3DwDpYqVRnO_YVMtA%40mail.gmail.com.

[Matt Farina]

Let me share that I'm +1 for a SIG working on tools for extending the Kubernetes platform.

To continue the justification, SIG Architecture has been talking about how Kubernetes is slowing down in terms of features being added and putting a focus on stability and extensibility. Several features requests have been directed to the ecosystem to start as a way to extend Kubernetes rather than starting in the core of Kuberentes. Those folks need better extension points and tools to help them. Some of this work has already started with tools like kubebuilder.

I'm not entirely sure where the term operators fits into this space and would be interested in more detail. Is it around the generation of operators? For example, the development of tools like operator-kit.

[Anthony Yeh]

> The one exception I'd say here is if this new SIG were going to take on client-go and really make that work for folks outside of the Kubernetes project itself.  It is a known pain point that, in my opinion, deserves attention. It is by far the top priority.

It's definitely within the proposed mission of SIG-PD to tackle the pain point of "interacting with the k8s API from outside the core". Things like operator-kit and kube-builder are effectively wrappers around client-go ("client-go for everyone else") to address exactly this pain point. Metacontroller is "client-go as a service" -- another way to address this pain point for certain use cases.

Whether and to what extent future progress on this mission involves SIG-PD working directly on client-go would be decided through collaboration with SIG-AM, but there's a lot SIG-PD can do to further this mission that doesn't depend on absorbing client-go itself.

This is also the reason that we think subprojects like kube-builder and metacontroller are different from things like FaaS frameworks built on top of k8s. As you said, solving this pain point should be a top priority for Kubernetes; we can't stop with the currently provided tools (only client-go at this point) and expect the ecosystem to do the rest.

These subprojects are our early attempts as Kubernetes maintainers to prototype solutions. We believe it's time to start formally collaborating and building opinionated, holistic answers to the question, "How do I extend the Kubernetes API?"

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAH16Sh%2BzvrCwdkaViYEucwywburoi4bXuug6T7fBLMt1bRXwAQ%40mail.gmail.com.

[jbe...@redhat.com]

Wait, how is this different from the Developer Tools WG that was proposed last week?

The two seem to be pretty much the exact same proposal, only with different groups of people, and one is a SIG and the other is a WG.  But both plan to cover the same tech, as far as I can tell.

On Monday, April 2, 2018 at 3:21:45 PM UTC-7, Jimmy Zelinskie wrote:

[Joe Beda]

I think that this is different from the WG proposal in that there is a difference between "How do I develop apps on top of Kubernetes?" and "How do I effectively extend Kubernetes?"

There is a commonality here in that it looks like the WG will fold in to and be driven by SIG-Apps (survey coming out) while this effort is proposing a whole new SIG for ~2 projects.  I'm pushing back because I think that it makes sense to fold this into SIG-AM vs. creating a new SIG similar to how it looks like we are probably not going to create a new WG.

Joe

--

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 post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/26dcb731-fa37-4b87-933a-b17951d1fb2d%40googlegroups.com.

[Clayton Coleman]

I might be so bold as to presume to speak for api machinery and say “we already have so much to do already that trying to cram one more thing in there is actually a bad idea”.

Expanding the AM charter with a bunch of new things seems undesirable.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEAFPYLDD_QuvqyEV4OJ%3D7v6rzmf5%3D8%2BnSy8_e-n9CwkFr_pOw%40mail.gmail.com.

[Joe Beda]

Presumably this new SIG will come with an injection of new people to work on these sub projects, yes?  I also think that there is a benefit to having folks that are *using* the stuff that SIG-AM being a part of the meetings and reporting experiences.  It will also facilitate people getting involved in actually improving our API usability through things like client-go and documentation (watch is still undocumented...)

Again -- at root this is 2-3 tangentially related subprojects (two of the listed need to be imported and we need to solve CLA issues).  I like the work in both of the projects I have access to but I don't think they justify a whole new SIG.

Joe

[Eric Tune]

I'm in favor of this new SIG.

I've recently found that there are more than a dozen libraries and frameworks for building Kubernetes API extensions on Github, which suggests a demand for better extension developer tools.  I hope this SIG will be able to organize this space.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEAFPY%2BQve%2BoJEQQptw_UX1z-39HgO1P5mLnMPDvTYxG4bvQSg%40mail.gmail.com.

[Joe Beda]

Eric -- would you support this SIG owning client-go?  That seems to be the PRIMARY issue with folks interacting with and extending Kubernetes?

I'd love to see client-go treated as a real deliverable with documentation and a customer focus.  That hasn't really been the case up until now.

Joe

[Eric Tune]

I would support it taking on ownership of clients at some future time, with the agreement of SIG-API-Machinery.

I think there is enough to be done in this space without moving existing code ownership, so I don't see it as a pre-condition.

I don't see client-go being the only issue, and improvements are being explored within the framework of SIG-API-Machinery.

[Tim St. Clair]

In order to for a new SIG to form a PR to the community repo should be
made to outline it's charter according to the template, and the
steering committee will rationalize that with the other SIGs and
working groups.

Please see: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md.

We should hash it out on a governance PR imo.

Cheers,
Tim


On Tue, Apr 3, 2018 at 2:22 PM, 'Eric Tune' via Kubernetes
developer/contributor discussion <kuberne...@googlegroups.com>
wrote:

> https://groups.google.com/d/msgid/kubernetes-dev/CAASt_VHiRmPZ-jCqOz51P%3Ds2YiY5mbLFOwH0s_o%3DR3udu%3DSixw%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

Cheers,
Timothy St. Clair

“Do all the good you can. By all the means you can. In all the ways
you can. In all the places you can. At all the times you can. To all
the people you can. As long as ever you can.”

[Joe Beda]

Since concretely we are talking about one project immediately (and perhaps two in the future if CLA issues can be worked out) I think that it seems reasonable to make this part of SIG-AM or SIG-Apps.  If this stuff hits critical mass (including client-go) it can always form a new SIG.

FWIW -- I think that we have too many SIGs as it is and I'd like us to find ways to make sure the ones we do have can be functional and scale.

Joe

[Eric Tune]

Is "number of coding projects" the determinant of SIG creation?

I think what should matter is number of potential members with common interest, and expected ability to serve our users.

Based on the number of +1s on the thread, there seems to be interest from current community members to have a SIG.

One measure of need to serve our users would be the number of github projects which are building API extensions. There are around 600 of these.

[Clayton Coleman]

So I'll push back just a little bit here - SIG API-Machinery is a high output, high responsibility sig, as is SIG-Apps with a ton of projects and existing things to manage.  Do we expect the SIG to make the determination it wants to carve off a part of it's charter and give it to another SIG?  If it's a new scope, then steering makes the decision?

In general I agree that too many SIGs is worse than too few.  Obviously nothing stops people from self-organizing and getting stuff done, but we don't want to encourage "hey I went and did this I'm a sig now!".  Likewise we want to have some sort of reasonable bar.

If API-Machinery and Apps together said "we should divest these things" by the current rules that has to be a SIG (to own them), but we also seem to have a sentiment that it's easy to create a SIG and hard to change them afterwards, so we need to be more cautious about just adding them.

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/26dcb731-fa37-4b87-933a-b17951d1fb2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEAFPYLDD_QuvqyEV4OJ%3D7v6rzmf5%3D8%2BnSy8_e-n9CwkFr_pOw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEAFPY%2BQve%2BoJEQQptw_UX1z-39HgO1P5mLnMPDvTYxG4bvQSg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--

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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEAFPY%2BF3%3DYv-2Of8L1%3D86CE9Tj_zBGqdx7C_D9AbLeXASUqQg%40mail.gmail.com.

[Joe Beda]

I'm going to echo Tim and suggest the folks proposing this create a PR and we can take it up at the steering committee level.  This is an awkward time as we are working on locking this stuff down so things are in transition and the rules are being tightened.  Also, there are some good "meta" discussions we really need to have vs. the nitty gritty details of this proposal.

Joe

Joe

To unsubscribe from this group and stop receiving emails from it, send an email to kubernetes-de...@googlegroups.com.
To post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/26dcb731-fa37-4b87-933a-b17951d1fb2d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEAFPYLDD_QuvqyEV4OJ%3D7v6rzmf5%3D8%2BnSy8_e-n9CwkFr_pOw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEAFPY%2BQve%2BoJEQQptw_UX1z-39HgO1P5mLnMPDvTYxG4bvQSg%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to kuberne...@googlegroups.com.

[Brian Grant]

I agree, now. SIG API machinery already has 10 subprojects and many more repos.

https://github.com/kubernetes/community/blob/master/sigs.yaml#L45

For the record, SIG SDK thread from October:

https://groups.google.com/d/msg/kubernetes-sig-apps/JHgL45SIrVQ/V_SHJ4ewBwAJ

On Tue, Apr 3, 2018 at 11:02 AM Clayton Coleman <ccol...@redhat.com> wrote:

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAH16Sh%2B2ve-kPP38256xwo71dJhhFXfWxDNOxCK10xiPrhKk4g%40mail.gmail.com.

[Matt Farina]

I can add an example that helps to see the interface between developer tools, SIG Apps, and the proposed SIG.

SIG Apps has a subproject in the Application CRD being used to describe an app. There's a CRD and associated controller (to help with a couple things). To build that we're using kubebuilder, a tool to help create CRDs and controllers. It does a bunch of work so people don't need to know how to write all the ins and outs of a controller. That knowledge isn't held by the masses. kubebuilder would, I think, be owned by this new SIG while SIG Apps would own the Application CRD/controller that uses it.

There are slightly different purposes.

Someone suggested to me that this effort group could be a sub-effort from SIG API Machinery rather than a full SIG. It could have it's own meetings and be a sub-group. Because it has so much overlap with SIG API Machinery the coupling could still be useful. I'm asking about this as a litmus test. What do folks think? This kind of thing has worked for SIG Apps.

[Brendan Burns]

I think we should really take this up at the steering committee level.

I feel like a SIG like this is scope-creep for the project.

Either it's "how do we make Kubernetes extensible" which clearly falls under APIMachinery

Or it's "tools and patterns on top of Kubernetes", in which case I really don't think it belongs in our organization at all.

I guess there is some middle ground for a:

SIG-SDK/Toolkits - which would basically be a set of building blocks for building things on top of Kubernetes, I could see owning all of the SDKs as well as things like the generic-apiserver codebase (though there's clearly cross-over with api-machinery there)

Basically the SIG wouldn't own any final products, but it would own a collection of libraries and starting templates that make it easier for people to build their own things on top of Kubernetes.

But that's about as far as I think it should go.  See my comments on the Developer Tools thread. IMHO, Kubernetes can not put itself in a place where it aspires (or even allows) tools that live on top of the project to become a part of the project.

--brendan

[Jessie Frazelle]

I would predict that a sig focused on "tools and patterns on top of
Kubernetes" with the current state of the ecosystem is going to be
very political.

Any sort of action items for how "hypothetical sig" needs to change
k8s core/etc would have to be run through API Machinery anyways afaict
so it kinda seems more like a user group or something.

But yeah, heed the warning of that being... for lack of a better
phrase... a political nightmare.

> --
> 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 post to this group, send email to kuberne...@googlegroups.com.
> To view this discussion on the web visit

> https://groups.google.com/d/msgid/kubernetes-dev/f5e8050c-566e-4788-ba3d-831b76338c14%40googlegroups.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC 511E 18F3 685C 0022 BFF3
pgp.mit.edu

[Matt Farina]

If we started by defining this sig by what it's sub-projects would be would it include the SDKs, operator-kit, kubebuilder, and something like metacontroller? Or, is there something different in mind?

[Matt Farina]

I would predict that a sig focused on "tools and patterns on top of
Kubernetes" with the current state of the ecosystem is going to be
very political.

There are a bunch of vendors jockeying for position. There are several cases of direct competition. Can we try to keep the Kubernetes community, meetings, and space in general as a very neutral place? That when vendors want to work on their own bits they can self organize adjacent to the community?

IMHO, Jess is right. Because there are companies around Kubernetes trying to make money, when Kuberenetes touches the ecosystem we need to be careful on how we operate and communicate things.

[Eric Tune]

The proposal does not use the words ""tools and patterns on top of Kubernetes".

Clearly that would be overly broad.  That is not being proposed.

The SIG would have narrow concerns like:

- Libraries that input/output our GoIDL and json-schema.

- Tools that lint generated APIs to ensure they are "kubernetes-like", e.g. that they have ObjectMeta.

- Tools which are optional to use and which generate certs for installing webhooks and extension apiservers.

On Wed, Apr 4, 2018 at 11:26 AM Matt Farina <matt....@gmail.com> wrote:

If we started by defining this sig by what it's sub-projects would be would it include the SDKs, operator-kit, kubebuilder, and something like metacontroller? Or, is there something different in mind?

--

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 post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/5c904f62-f48f-4015-a95a-457c988edb16%40googlegroups.com.

[Anthony Yeh]

I added some specific responses inline below, but I wanted to first address the general sentiment that this doesn't sound like a good use case for a SIG.

I think some of the discrepancy in viewpoints is coming from an unstated assumption we (the proposers of SIG-PD) made that it turns out does not have broad consensus yet.

Namely: We believe the Kubernetes project should eventually distribute a first-party kit of tools, templates, and documentation aimed specifically at developers who want to build extensions to the Kubernetes API. This would be analogous to things like the Driver Development Kit for Windows, or the kit that (presumably?) Google gives to phone OEMs to help them customize Android. Note that these are different from the Windows SDK and Android SDK for writing apps that run on top of these platforms.

Personally I don't think any of the proposed initial subprojects are on a path that will converge toward such a thing, and that's exactly why I want to bring all the contributors to those projects into one SIG with a focused mission to produce and continue to maintain that deliverable at some time (potentially far) in the future. If it makes sense to bring those people in without bringing the projects, I'm fine with that. I don't think either SIG-AM or SIG-Apps alone is the right place though, and I absolutely want all these people in one place.

However, we don't seem to have consensus that such a deliverable is a goal of the Kubernetes project. Given that, I would tend to agree it's too soon to start a SIG for it.

Since this issue touches both SIG-AM and SIG-Apps in meaningful ways, maybe we first need a WG to answer the question of whether the Kubernetes project should pursue this goal. This would be a temporary WG that would disband once the question is answered and a plan is formed for how to get started (if the answer is yes).

Below are some specific inline responses:

> Please see: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md.

I don't think we're at that stage yet. We're on step 1 of this procedure:

https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-and-maintenance-procedure

"""

Propose the new SIG publicly, including a brief mission statement, by emailing kuberne...@googlegroups.com and kubernet...@googlegroups.com, then wait a couple of days for feedback

"""

> I guess there is some middle ground for a: SIG-SDK/Toolkits

> [...]

> it would own a collection of libraries and starting templates that make it easier for people to build their own things

This is exactly what we're proposing. We couldn't call it SIG-SDK because SDK on its own might sound like a kit for developing application software that runs on top of Kubernetes. What we propose to work towards in this SIG is a Platform Development Kit for developers building extensions to the Kubernetes platform.

> I would predict that a sig focused on "tools and patterns on top of

Kubernetes" with the current state of the ecosystem is going to be

very political.

With a broad interpretation of "tools on top of k8s", I agree. Do you think this concern also applies to the more narrow, "tools for people who build tools on top of k8s"?

As an example, currently the set of first-party tools for this case consists of client-go (I don't count the other language clients in this specific case since they don't have all the machinery for developing first-class controllers, like informers). I haven't seen entities in the ecosystem trying to compete on producing a better client-go. I think it's up to us to do that, and as I said earlier kubebuilder and metacontroller are prototypes of how we might approach doing so.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEk6tEwJSaE1RJM4CDMv%3DjczeZQdnDPD%3D-3UamaQHcctY7%2B9yQ%40mail.gmail.com.

[Phillip Wittrock]

Adding my $0.02

• It is ok and necessary for some SIGs to be cross-cutting.  We have a number of cross-cutting SIGs today and they have proven critical - release, contrib-x and docs are all examples.  It is also normal for SIGs to consume artifacts produced by other SIGs and build on top of them.  SIG cli has built libraries on top of the SIG apimachinery libraries.
• The focus of this SIG would be providing guidance and a holistic approach for building Kubernetes APIs through the core extension mechanisms.
• While parts of the problem space fall under apimachinery, there are also parts that do not.  A number of API developers are packaging custom cli's for their extensions, developers will need a way to integration test / e2e test their extensions, developers should be able to product reference documentation for their APIS.

The steps to build a complete and polished Kubernetes extension cut across at least 4-5 sigs (apimachinery, apps, cli, docs, testing).  Addressing the challenges to holistic API development will require building libraries, tools and documentation that integrate low-level components owned by each of these SIGs.  Since working groups do not own code we will need to find a home for owning these cross cutting integrations.

- Phil

On Tue, Apr 3, 2018 at 8:52 AM Joe Beda <j...@heptio.com> wrote:

The process on how to charter a SIG and the lines between them is still being defined but my understanding is that it was up tot he steering committee to decide what SIGs we had and the scope of each SIG while it is up to SIG-architecture to define the scope of Kubernetes as a whole.

If the steering committee thinks this stuff may be out of scope for Kubernetes then we can punt this to SIG-architecture.

Regardless -- let me boil my mail down to 3 things to consider:

• Why can't this be subprojects of SIG-API-Machinery? [steering]
• If this is a new SIG, does it have meaty enough things to start with without client-go? [steering]
• Are the proposed sub-projects in scope for k8s at all? [sig-architecture]

Joe

To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAEAFPYJ-rc6MtF%3DviWpy4UJxjyDgqLn9iU%2BJ4BvikCC%2Bc6cz5w%40mail.gmail.com.

[Clayton Coleman]

On Wed, Apr 4, 2018 at 2:43 PM, 'Anthony Yeh' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

I added some specific responses inline below, but I wanted to first address the general sentiment that this doesn't sound like a good use case for a SIG.

I think some of the discrepancy in viewpoints is coming from an unstated assumption we (the proposers of SIG-PD) made that it turns out does not have broad consensus yet.

Namely: We believe the Kubernetes project should eventually distribute a first-party kit of tools, templates, and documentation aimed specifically at developers who want to build extensions to the Kubernetes API. This would be analogous to things like the Driver Development Kit for Windows, or the kit that (presumably?) Google gives to phone OEMs to help them customize Android. Note that these are different from the Windows SDK and Android SDK for writing apps that run on top of these platforms.

Personally I don't think any of the proposed initial subprojects are on a path that will converge toward such a thing, and that's exactly why I want to bring all the contributors to those projects into one SIG with a focused mission to produce and continue to maintain that deliverable at some time (potentially far) in the future. If it makes sense to bring those people in without bringing the projects, I'm fine with that. I don't think either SIG-AM or SIG-Apps alone is the right place though, and I absolutely want all these people in one place.

However, we don't seem to have consensus that such a deliverable is a goal of the Kubernetes project. Given that, I would tend to agree it's too soon to start a SIG for it.

Since this issue touches both SIG-AM and SIG-Apps in meaningful ways, maybe we first need a WG to answer the question of whether the Kubernetes project should pursue this goal. This would be a temporary WG that would disband once the question is answered and a plan is formed for how to get started (if the answer is yes).

Below are some specific inline responses:

> Please see: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md.

I don't think we're at that stage yet. We're on step 1 of this procedure:

https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-and-maintenance-procedure

"""

Propose the new SIG publicly, including a brief mission statement, by emailing kubernetes-dev@googlegroups.com and kubernetes-users@googlegroups.com, then wait a couple of days for feedback

"""

> I guess there is some middle ground for a: SIG-SDK/Toolkits

> [...]

> it would own a collection of libraries and starting templates that make it easier for people to build their own things

This is exactly what we're proposing. We couldn't call it SIG-SDK because SDK on its own might sound like a kit for developing application software that runs on top of Kubernetes. What we propose to work towards in this SIG is a Platform Development Kit for developers building extensions to the Kubernetes platform.

> I would predict that a sig focused on "tools and patterns on top of

Kubernetes" with the current state of the ecosystem is going to be

very political.

With a broad interpretation of "tools on top of k8s", I agree. Do you think this concern also applies to the more narrow, "tools for people who build tools on top of k8s"?

As an example, currently the set of first-party tools for this case consists of client-go (I don't count the other language clients in this specific case since they don't have all the machinery for developing first-class controllers, like informers). I haven't seen entities in the ecosystem trying to compete on producing a better client-go. I think it's up to us to do that, and as I said earlier kubebuilder and metacontroller are prototypes of how we might approach doing so.

+1.  Client-go (and better client-go) are necessary but not sufficient.  CRD is necessary but not sufficient.  An SDK is much broader than either of those.

 

> email to kubernetes-dev+unsubscribe@googlegroups.com.
> To post to this group, send email to kubernetes-dev@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/f5e8050c-566e-4788-ba3d-831b76338c14%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--


Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu

--
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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEk6tEwJSaE1RJM4CDMv%3DjczeZQdnDPD%3D-3UamaQHcctY7%2B9yQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--

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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAFdFTS0LL4%3D_VBVYQHU92YgjaggO1EdyJesyicLHrpAJOXJPPw%40mail.gmail.com.

[Daniel Smith]

On Wed, Apr 4, 2018 at 11:32 AM 'Eric Tune' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

The proposal does not use the words ""tools and patterns on top of Kubernetes".

Clearly that would be overly broad.  That is not being proposed.

The SIG would have narrow concerns like:

- Libraries that input/output our GoIDL and json-schema.

I think API Machinery needs to own this toolchain. It needs to remain in tight correspondence with the handler stack that apiserver uses.

 

- Tools that lint generated APIs to ensure they are "kubernetes-like", e.g. that they have ObjectMeta.

I think this covers some items that api machinery needs to own and some that it doesn't have to own.

 

- Tools which are optional to use and which generate certs for installing webhooks and extension apiservers.

I agree that this isn't essential to api machinery's core mission and realistically, we're not going to get to it soon.

 

On Wed, Apr 4, 2018 at 11:26 AM Matt Farina <matt....@gmail.com> wrote:

If we started by defining this sig by what it's sub-projects would be would it include the SDKs, operator-kit, kubebuilder, and something like metacontroller? Or, is there something different in mind?

--
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 post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/5c904f62-f48f-4015-a95a-457c988edb16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAASt_VG0BgWgi6zsvJxzZ0XO6xt82MuqjKBa9iU4HsPjq%3DpRpQ%40mail.gmail.com.

[Nick Young]

I don't really have much of a position on a lot of this, but would like to say that I would love to see some more work around

> - Tools which are optional to use and which generate certs for installing webhooks and extension apiservers.

Currently, this is definitely a pain point. More tooling and documentation around generating certs and which certs to put where would be very welcome.

- Nick

On 5 April 2018 at 04:31, 'Eric Tune' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

The proposal does not use the words ""tools and patterns on top of Kubernetes".

Clearly that would be overly broad.  That is not being proposed.

The SIG would have narrow concerns like:

- Libraries that input/output our GoIDL and json-schema.

- Tools that lint generated APIs to ensure they are "kubernetes-like", e.g. that they have ObjectMeta.

- Tools which are optional to use and which generate certs for installing webhooks and extension apiservers.

On Wed, Apr 4, 2018 at 11:26 AM Matt Farina <matt....@gmail.com> wrote:

If we started by defining this sig by what it's sub-projects would be would it include the SDKs, operator-kit, kubebuilder, and something like metacontroller? Or, is there something different in mind?

--
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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/5c904f62-f48f-4015-a95a-457c988edb16%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

--

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-dev+unsubscribe@googlegroups.com.
To post to this group, send email to kubernetes-dev@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAASt_VG0BgWgi6zsvJxzZ0XO6xt82MuqjKBa9iU4HsPjq%3DpRpQ%40mail.gmail.com.

[Brian Grant]

On Wed, Apr 4, 2018 at 12:17 PM Clayton Coleman <ccol...@redhat.com> wrote:

On Wed, Apr 4, 2018 at 2:43 PM, 'Anthony Yeh' via Kubernetes developer/contributor discussion <kuberne...@googlegroups.com> wrote:

I added some specific responses inline below, but I wanted to first address the general sentiment that this doesn't sound like a good use case for a SIG.

I think some of the discrepancy in viewpoints is coming from an unstated assumption we (the proposers of SIG-PD) made that it turns out does not have broad consensus yet.

Namely: We believe the Kubernetes project should eventually distribute a first-party kit of tools, templates, and documentation aimed specifically at developers who want to build extensions to the Kubernetes API. This would be analogous to things like the Driver Development Kit for Windows, or the kit that (presumably?) Google gives to phone OEMs to help them customize Android. Note that these are different from the Windows SDK and Android SDK for writing apps that run on top of these platforms.

Personally I don't think any of the proposed initial subprojects are on a path that will converge toward such a thing, and that's exactly why I want to bring all the contributors to those projects into one SIG with a focused mission to produce and continue to maintain that deliverable at some time (potentially far) in the future. If it makes sense to bring those people in without bringing the projects, I'm fine with that. I don't think either SIG-AM or SIG-Apps alone is the right place though, and I absolutely want all these people in one place.

However, we don't seem to have consensus that such a deliverable is a goal of the Kubernetes project. Given that, I would tend to agree it's too soon to start a SIG for it.

Since this issue touches both SIG-AM and SIG-Apps in meaningful ways, maybe we first need a WG to answer the question of whether the Kubernetes project should pursue this goal. This would be a temporary WG that would disband once the question is answered and a plan is formed for how to get started (if the answer is yes).

Below are some specific inline responses:

> Please see: https://github.com/kubernetes/community/blob/master/committee-steering/governance/sig-governance-template-short.md.

I don't think we're at that stage yet. We're on step 1 of this procedure:

https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-and-maintenance-procedure

"""

Propose the new SIG publicly, including a brief mission statement, by emailing kuberne...@googlegroups.com and kubernet...@googlegroups.com, then wait a couple of days for feedback

"""

> I guess there is some middle ground for a: SIG-SDK/Toolkits

> [...]

> it would own a collection of libraries and starting templates that make it easier for people to build their own things

This is exactly what we're proposing. We couldn't call it SIG-SDK because SDK on its own might sound like a kit for developing application software that runs on top of Kubernetes. What we propose to work towards in this SIG is a Platform Development Kit for developers building extensions to the Kubernetes platform.

> I would predict that a sig focused on "tools and patterns on top of

Kubernetes" with the current state of the ecosystem is going to be

very political.

With a broad interpretation of "tools on top of k8s", I agree. Do you think this concern also applies to the more narrow, "tools for people who build tools on top of k8s"?

As an example, currently the set of first-party tools for this case consists of client-go (I don't count the other language clients in this specific case since they don't have all the machinery for developing first-class controllers, like informers). I haven't seen entities in the ecosystem trying to compete on producing a better client-go. I think it's up to us to do that, and as I said earlier kubebuilder and metacontroller are prototypes of how we might approach doing so.

+1.  Client-go (and better client-go) are necessary but not sufficient.  CRD is necessary but not sufficient.  An SDK is much broader than either of those.

+1. If we intend Kubernetes to really be a platform for developing on top, it needs SDKs. It's too hard for US to add functionality to K8s right now.

If we wanted to start in API machinery, we could split it out later. kubebuilder already landed in API machinery. This would start as one or two additional subprojects. We could revisit once API machinery has 15 or 20 subprojects.

Practically speaking, I think this group will at least need its own meetings, but many other subprojects already do that.

 

 

> email to kubernetes-de...@googlegroups.com.
> To post to this group, send email to kuberne...@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msgid/kubernetes-dev/f5e8050c-566e-4788-ba3d-831b76338c14%40googlegroups.com.
>
> For more options, visit https://groups.google.com/d/optout.



--


Jessie Frazelle
4096R / D4C4 DD60 0D66 F65A 8EFC  511E 18F3 685C 0022 BFF3
pgp.mit.edu

--
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 post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAEk6tEwJSaE1RJM4CDMv%3DjczeZQdnDPD%3D-3UamaQHcctY7%2B9yQ%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAFdFTS0LL4%3D_VBVYQHU92YgjaggO1EdyJesyicLHrpAJOXJPPw%40mail.gmail.com.

For more options, visit https://groups.google.com/d/optout.

--
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 post to this group, send email to kuberne...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAH16ShKajAjyrc9EfD95v-x6CMVjfoNCiQaxxypstNa%3DU0yGfA%40mail.gmail.com.

[Tim Hockin]

I read the whole thread.  I find myself nodding in approval for:

A) first-party XDKs (extension dev kits) seem appropriate for the project overall

B) client-go is insufficient for most users as it stands

C) caution is required as to the bounds of this proposal.  I don't think it is scope creep YET, but it seems open-ended and could easily become so

I care pretty much not at all for the politics.  I know some companies are making a lot of noise about developer tools, but I think this is bigger than that.  It's clear to me that kubernetes the platform is as important as kubernetes the container system.

So as much as I don't want more SIGs, I am +1 on this, assuming apimachinery and apps are cool with the assumption of some of their charters.  If we want to jam this somewhere for a while, I can live with that, but I think the work should happen and I think this organization is likely inevitable.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAKCBhs5HO-Ecruda%3DJgwvUDCQ2jrSRwLJMZPJRuHj4Whp4qUbw%40mail.gmail.com.

[Joe Beda]

I want to echo Tim St. Clair's call to discuss this at the Steering Committee.  IMO, we need to get more formal around the process of chartering new SIGs and deciding the boundaries between SIGs.  A formal proposal for a charter in a PR would also help to make sure we are all talking about the same thing.  There is a BIG difference between what was proposed in the first message in this thread and any sort of SIG-SDK.  I'd like to know what exactly is being proposed at this point.

Joe

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAO_RewbKKK8c7FJ_3LFULi8U-uGHRt%3DYTMZmArnqvnTMp05KXw%40mail.gmail.com.

[Clayton Coleman]

On Apr 5, 2018, at 11:09 AM, Joe Beda <j...@heptio.com> wrote:

I want to echo Tim St. Clair's call to discuss this at the Steering Committee.  IMO, we need to get more formal around the process of chartering new SIGs and deciding the boundaries between SIGs.  A formal proposal for a charter in a PR would also help to make sure we are all talking about the same thing.  There is a BIG difference between what was proposed in the first message in this thread and any sort of SIG-SDK. 

Huh - didn’t seem that way to me, but could just be terminology.  Develop software on Kube = runs well on Kube = extends Kube with new capabilities = SDK.  SDKs as I’ve always thought about them are about people being successful extending / using a platform, catered to the specific nuances of the platform.  So Windows SDK is about building Windows apps, but Kube SDK is about building and running cloud native services with APIs that use controllers to dynamically create managed software and continuously reconcile those.

I think this is distinguished from building arbitrary apps on Kube or developing on top of Kube by virtue of extending Kube and being Kube native in how you extend it, but may just be my familiarity with the language Jimmy used.

[Tim St. Clair]

The steering committee is in charge of governance of the project, and
we should strive to adhere to the processes that we have started by
PR-ing a proposed charter according to the template that Phil has
worked diligently on.

Athenian democracy doesn't scale and leads to bad outcomes IMO.

Cheers,
Tim

> https://groups.google.com/d/msgid/kubernetes-dev/CAH16ShK%2BB4uvDDmkXi%3DxVd%3D3Omk4U05opJnpf4pW8zGXS-0%3DcQ%40mail.gmail.com.

>
> For more options, visit https://groups.google.com/d/optout.



--

[Clayton Coleman]

> On Apr 5, 2018, at 12:30 PM, Tim St. Clair <timo...@gmail.com> wrote:
>
> The steering committee is in charge of governance of the project, and
> we should strive to adhere to the processes that we have started by
> PR-ing a proposed charter according to the template that Phil has
> worked diligently on.
>
> Athenian democracy doesn't scale and leads to bad outcomes IMO.

I was responding to Joe’s comment about the mission changing, not to
the steering committee part. I of course agree that we need to do a
better job testing out our new processes with the community and making
sure they are solving community problems.

[Joe Beda]

Last word here to respond to Clayton.  If this new SIG included client-go (improving it, documenting it, etc) then I think it is the start of SIG-SDK.  If it doesn't and just includes some sub-projects that may or may not belong in k8s, then I think the case is a lot less strong.  That is the thing that I'd like to see clarified int he charter.  My opinion is that any SDK starts with client-go and need to be used for our internal components.  The SDK is something for both building the "user mode" of k8s along with allowing folks to extend it.

Joe

[Clayton Coleman]

Thanks, that helps me see where you are coming from here.

[Brian Grant]

I agree that externally consumable client libraries belong in the same group.

[Anthony Yeh]

Can someone point me to the instructions for the PR that is being requested?

The sig governance template that Tim linked earlier is only about how the SIG runs itself after it exists. As far as I can see, the template has no recommendations about how/where to propose a new SIG, nor any recommendations on defining the scope of the SIG (which is the important point of contention here). I could fill out the template, but it wouldn't say anything useful about the discussion we've been having.

I'm happy to get started on the new SIG proposal process if one exists. All I've found so far is this link:

https://github.com/kubernetes/community/blob/master/sig-governance.md#sig-creation-procedure

Step 1 is to send a "brief mission statement" to the mailing list, which we have done here.

Steps 2-10 assume that the new SIG was approved, so we are not there yet.

[Joe Beda]

Hi Anthony,

I'm sorry that this is a frustrating procedure.  We are in the process that of getting this stuff reworked right now.  I have some changes going in in https://github.com/kubernetes/community/pull/1994 but that doesn't totally address the problem.

Over the coming months we are going to be looking to have every SIG have a somewhat more formal charter in place with rules and processes clearly articulated.  We are gearing up for that.  The assumption here (not written down clearly yet) is that new SIGs should start off on the right foot with a charter.

Y'all did a great job following the process clearly described but not where we want to be taking it.  That is frustrating for sure.  Those instructions date from before we had a steering committee to help curate the set of SIGs and ensure that they were scoped appropriately and not overlapping.

Joe

[Joe Beda]

More context on how these processes are WIP: https://github.com/kubernetes/community/issues/1997

[Anthony Yeh]

Thanks for the context. I definitely understand the desire to avoid creating new debt while trying to migrate to the new process. I feel better just knowing that I wasn't crazy for not being able to find anything about this PR process people keep referring to. :)

I'll talk with Jimmy and we'll start putting together a proposed charter in a PR against k/community, based on our best interpretation of the available docs on the new process. We can always update the PR as the process solidifies.

Thanks everyone for the great points raised on this thread. We'll try to summarize and reconcile them in the PR and go from there. I'll be sure to send a link to the PR once it's created to close the loop on this.

[Joe Beda]

Joe

--

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 post to this group, send email to kuberne...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/6d196ba8-657b-4267-b332-94c30376b338%40googlegroups.com.

For more options, visit https://groups.google.com/d/optout.

--

You received this message because you are subscribed to the Google Groups "steering" group.

To unsubscribe from this group and stop receiving emails from it, send an email to steering+u...@kubernetes.io.
To post to this group, send email to stee...@kubernetes.io.
Visit this group at https://groups.google.com/a/kubernetes.io/group/steering/.

To view this discussion on the web visit https://groups.google.com/a/kubernetes.io/d/msgid/steering/CAEAFPYJOkz31Lxx660o7M%3DNw_ssJ1OpVUn%3DwDpYqVRnO_YVMtA%40mail.gmail.com.

[Anthony Yeh]

As promised, here's the link to the PR:

https://github.com/kubernetes/community/pull/2033

Please consolidate any further discussion there.

Thanks,

Anthony