WG rationalization and application-oriented groups

50 views
Skip to first unread message

Brian Grant

unread,
Apr 20, 2018, 2:18:06 PM4/20/18
to steering
Most of our current WGs should not be WGs:
  • App Def WG: It has spawned efforts in SIG Apps, SIG CLI, and SIG API machinery, but the latter 2 SIGs are no longer involved, so it could be folded back into SIG Apps at this point.
  • Apply WG: This is just a feature-related effort. It doesn't need a WG.
  • Cloud provider WG: This should be an effort or subproject of a SIG Cloud Provider (or whatever we want to call that).
  • Cluster API WG: SIG Cluster Lifecycle subproject
  • Container identity WG: Seems like a SIG Auth subproject
  • Kubeadm adoption WG: Kubeadm is a SIG cluster lifecycle subproject. 
  • Machine Learning WG: Will cover that below.
  • Multi-tenancy WG: Ok, this should be a WG.
  • Policy WG: Also a WG.
  • Resource management WG: Seems to contradict the idea that WGs should have specific goals and not live forever.
We have several groups focused on applications that run on Kubernetes:
  • SIG Apps (everything other than workload APIs)
  • SIG Big Data
  • Machine Learning WG
  • the proposed IoT/Edge WG
At some point we had some spark work in the Kubernetes github org, but SIG Big Data doesn't currently own any code in Kubernetes, and isn't likely to.

I think there are useful things such groups could produce, such as:
  • Documentation of key user profiles, use cases, and user journeys
  • Potentially how-to guides if no specific additional tools/extensions are necessary
  • Specs for common concepts and/or extension APIs, to improve interoperability
  • Proposals and code for improvements to the core needed to support those use cases
But we need a consistent policy about where such efforts belong and what we expect from them.

If we were going to undertake such efforts under the project, I'd distinguish them from WGs (application groups?) or make them a special variety of WG in order to provide more clarity.


Quinton Hoole

unread,
Apr 20, 2018, 4:53:10 PM4/20/18
to Brian Grant, steering
Brian, could you please post a link to the canonical definition of a working group?
I want to make sure that I’m reading the right version of that, and that I understand that before commenting further.

I am (perhaps mistakenly) under the impression that WG’s live inside SIGs.

Q

--
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/CAKCBhs4qZFuQ_UxiEwQv_oWE7wQjOLEuMOK%2BQCcFbTReEO%3DGRA%40mail.gmail.com.

Brian Grant

unread,
Apr 20, 2018, 5:58:55 PM4/20/18
to Quinton Hoole, steering
On Fri, Apr 20, 2018 at 1:53 PM Quinton Hoole <quinto...@huawei.com> wrote:
Brian, could you please post a link to the canonical definition of a working group?
I want to make sure that I’m reading the right version of that, and that I understand that before commenting further.

I am (perhaps mistakenly) under the impression that WG’s live inside SIGs.

WGs are for cross-SIG efforts, not intra-SIG ones:

Joe's PR in progress to try to clarify some of this:

Quinton Hoole

unread,
Apr 20, 2018, 7:23:35 PM4/20/18
to Brian Grant, steering
OK, so working groups are:
  1. required to be sponsored by one or more SIG’s, 
  2. encouraged to report back and act through those SIG’s.
  3. supposed to be easy create and deprecate once inactive.
It seems that we should just follow the above, and not over-complicate matters. 

Specifically:
  • App Def WG – Leave it to SIG Apps to decide whether to deprecate it, or produce a charter, find a second sponsor SIG and produce defined artifacts.  Default to deprecate.
  • App WG – Go and find two sponsor SIG’s, or default to being deprecated.
  • Cloud Provider WG – Become a real SIG, or default to being deprecated.
  • Cluster API WG — Leave it to SIG Cluster Lifecycle to decide whether to deprecate it, or produce a charter, find a second sponsor SIG and produce defined artifacts.  Default to deprecate.
  • Container Identity —Leave it to SIG Auth to decide whether to deprecate it, or produce a charter, additional sponsor SIG and produce defined artifacts.  Default to deprecate.
  • Kubeadm adoption WG -  Leave it to SIG Cluster Lifecycle to decide whether to deprecate it, or produce a charter and defined artifacts.  Default to deprecate.
… Etc.

Q

Brian Grant

unread,
Apr 20, 2018, 9:07:58 PM4/20/18
to Quinton Hoole, steering
Sorry I wasn't clear about the problems I was trying to solve, but I think your responses confirmed that they are indeed problems :-).

I want to reduce confusion about:
  • the difference between subprojects and working groups
  • the difference between working groups and just efforts within a subproject
  • the difference between working groups and SIGs
  • what should be working groups vs. unofficial groups

Derek Carr

unread,
Apr 23, 2018, 10:53:38 AM4/23/18
to Brian Grant, Quinton Hoole, steering
If I am not mistaken, WGs predate sub-projects, so the confusion on reconciling the two is not surprising.

>the difference between subprojects and working groups

my understanding was that subprojects maintain a body of code within the domain of a single sig.

>the difference between working groups and just efforts within a subproject

my understanding was that working groups spanned sigs as they are attempting to drive discussion, design, and development roadmaps for a topic area across sigs.  once a clear technical approach is identified among the relevant sigs for a topic area, execution of that code should be managed within the proper sigs and subprojects.  as an example, in wg-resource-mgmt, we wanted to support cpu scheduling.  in the beginning, it was not clear if this was the domain of sig-scheduling or sig-node.  the wg reached a design consensus that kept the concept in the domain of sig-node and implementation of the feature in the kubelet subproject.  the present items under discussion in that work group (device plugin monitoring and metadata around resource apis) are following a similar pattern across sig-instrumentation, sig-scheduling, and sig-node.

the major difference i see which is a working group is a forum to resolve cross sig design issues.

>the difference between working groups and sigs

the governance says "is short lived or spans multiple sigs".  this thread is implying a desire to make it "is short lived and spans multiple sigs".  either approach is fine to me.  this was a topic of recent discussion in wg-resource-mgmt.  in my opinion, there are still technical topics in that wg that need closure around device plugins and resource apis that span multiple sigs.  once closure on design approach is achieved, execution can happen in the owning sig/sub-project (i.e. sig-node, sig-instrumentation, sig-scheduling).  it is neither my intent or desire to have the wg run forever, but i tend to agree with Quinton that working groups that no longer serve the sponsoring sigs well should just become inactive but its a sig decision.

>what should be working groups vs unofficial groups

i think a working group should have sponsorship from more than one sig and track a topic area that is an accepted part of the core project roadmap.

Thanks,
Derek





--
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+unsubscribe@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/CAKCBhs4VqYEhuH2Apkcu1KmRp7_-awG4u0yBw0ou-d2drqy8kA%40mail.gmail.com.

Brian Grant

unread,
Apr 23, 2018, 11:23:23 PM4/23/18
to Derek Carr, Quinton Hoole, steering
On Mon, Apr 23, 2018 at 7:53 AM Derek Carr <dec...@redhat.com> wrote:
If I am not mistaken, WGs predate sub-projects, so the confusion on reconciling the two is not surprising.

As a formal concept, yes, but informally, subprojects have existed for a long time. But, no, not surprising. 

>the difference between subprojects and working groups

my understanding was that subprojects maintain a body of code within the domain of a single sig.

Your understandings are consistent with the intent.

Documenting the differences is definitely one thing we should do (go for it! :-)), but I think it doesn't help that several existing groups deviate from the intent.
 
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/.

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

Derek Carr

unread,
May 2, 2018, 9:08:58 PM5/2/18
to Brian Grant, Quinton Hoole, steering
I will look to document the difference discussed in this thread this week so we enforce it for future efforts.  I agree we need to figure out how to address those that currently deviate.

Reply all
Reply to author
Forward
0 new messages