Re: New SIG Proposal: Platform Dev

[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

On Mon, Apr 2, 2018 at 3:21 PM Jimmy Zelinskie <ji...@redhat.com> wrote:

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)

--
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.

[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.

[Joe Beda]

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

[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?"

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

To view this discussion on the web visit https://groups.google.com/d/msgid/kubernetes-dev/CAH16Sh%2BzvrCwdkaViYEucwywburoi4bXuug6T7fBLMt1bRXwAQ%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

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.