-
Notifications
You must be signed in to change notification settings - Fork 5.2k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
set up SIG-etcd #7372
set up SIG-etcd #7372
Conversation
Skipping CI for Draft Pull Request. |
Conceptually this a +1 from me. We all need to see etcd through to a more stable ground. The Kubernetes project can try to foster that. But we really need to see the general shape of a charter, how the project will remain usable for existing non-Kubernetes, and get into the details of how that varies from our normal K8s SIG related processes and tools. |
+1 |
+1'ing @tpepper 's statements, we discussed it a bit during the steering meeting today. Overall we are good with the concept of bringing on etcd as a SIG. For explicit next steps -
|
@tpepper @mrbobbytables Please check out first section of SIG-etcd Charter & Vision.
Could we create a dedicated document with a checklist? I wanted Do's and don'ts of etcd SIG-ifycation to address that, but the list might long enough to motivate a separate document. |
To elaborate a little ...
Most SIG Charters are pretty close to the generic boilerplate SIG charter with some details filled in as to what the SIG owns, some of them the only thing to approve is that they will exist and what they will own (since steering delegates all ownership/technical decisions to the SIGs we want to make sure there's reasonably boundaries between them). Some SIGs are e.g. trying deviations in further expanding leadership positions or other things which are edited in and called out in their charters. We expect etcd will have some similar exceptions, like keeping it's own github organization instead of "donating" repos into github.com/kubernetes-sigs (most new projects), which raises some questions about ownership and management (github.com/kubernetes, github.com/kubernetes-sigs and other orgs are managed by a subproject of SIG Contributor Experience, enabling things like required 2FA and enforcing the CLA bot on all repos). We'll want to understand what those exceptions are. Otherwise spelling out the scope of SIG-etcd + the boilerplate should be sufficient. Also to further underline: We had all members in attendance at the mentioned public steering committee meeting and again everyone is supportive, we're just looking to etcd for what exceptions are required vs the standard SIG charter so we can make sure those are understood and agreed by everyone. Besides the boilerplate text we have 30+ existing groups to reference and I'm happy to help answer any clarifying questions, just send me a note. |
we should probably have @ahrtr apply for org membership :-) |
Yeah, I was reaching out to @serathius to ask him to join. He also should probably sign up for slack. |
sig-etcd/charter.md
Outdated
### Deviations from [kubernetes-repositories] | ||
|
||
- SIG etcd repositories live in github.com/etcd-io | ||
- SIG etcd repositories should (but not must) adopt merge bot, Kubernetes PR commands/bot, OWNERS file. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will require our contributors to apply for Kubernetes Org membership. That's probably a good thing overall, but will involve some bootstrapping.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That's not true, I expect similar to Kubernetes Org vs Kubernetes-SIGs Org, the membership will be separated from Kubernetes.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not, even kubernetes sigs have to apply for membership through org.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
yup - our orgs all use the same process of applying. Essentially you apply and if approved you can join any of the primary k8s orgs.
I mentioned out of band (#7372 (comment)) but to directly comment here on some of the hard reqs:
- etcd org is owned and managed by k8s OR repos are transferred to K8s org (NOTE: people can still be granted repo admin rights, its just management of the org)
- membership will be managed by our our automation and applying for org membership will use our process (current etcd org members wouldn't have to apply, we'd directly add)
- EasyCLA will be enabled on the etcd org or any repos transferred to K8s org
- github actions or the CI currently in play can still be used, but we'd still have to run our global stuff (e.g. cncf-cla, lgtm/approve etc.)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for bringing this up, Josh. I have no problem with that.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
One comment on the owners files, I think those will be a "must" insofar as we can link to the people responsible for the management of the subproject.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I am ok with that, do we just need a k8s style OWNERS file in the top level of each subproject under https://github.com/etcd-io?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sounds good to me too!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
+1 sounds good to me.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Removed the "OWNERS file" from deviation, and added an issue in etcd repo to track the effort of adding top level OWNERS file in each subproject repo: etcd-io/etcd#16367
To be clear - there are a few hard requirements if etcd wants to be a k8s sig and use our tooling & automation + SRC/CoCC etc:
EDIT: github actions or the CI currently in play can still be used, but we'd still have to run our global stuff (e.g. cncf-cla check) |
Thanks @mrbobbytables for providing the list. I don't think this will be a problem. cc @ahrtr @ptabor @spzala @mitake |
bb9fbac
to
09e5fcc
Compare
@mrbobbytables we should default add all existing etcd maintainers to kubernetes org, imo. |
@logicalhan I agree. I think just before we start doing that on a large scale we should sort out the charter etc. |
Steering Votes: |
Thanks @palnabarun . Friendly ping @cblecker @justaugustus @tpepper , please let us know if there is any other concerns. Thanks! |
/approve |
|
||
## Scope | ||
|
||
Owns the etcd project and how it is used by Kubernetes. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
note that you gain ownership of the current, very cumbersome and undeterministic process of updating etcd server/client in k8s.
this is currently a best effort from community members and issues and PRs just run stale:
kubernetes/kubernetes#117648
https://github.com/kubernetes/kubernetes/issues?q=is%3Aopen+label%3Aarea%2Fkubeadm+etcd
various product tooling allows some form of etcd version customization, custom images, fips builds, etc. thus the public updates are not a p0-1.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Historically it were etcd maintainers who bumped the etcd image in Kubernetes. Reason was that Kubernetes scalability tests are the major signal in etcd qualification, so minor bumps etcd version were done immediately.
What's more cumbersome is security patching, which is a problem because there are the etcd k8s image is also used by kubeadm. With the SIG in place, I think we can discuss changing/improving the release process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Historically it were etcd maintainers who bumped the etcd image in Kubernetes. Reason was that Kubernetes scalability tests are the major signal in etcd qualification, so minor bumps etcd version were done immediately.
i think i vaguelly recall this period.
What's more cumbersome is security patching, which is a problem because there are the etcd k8s image is also used by kubeadm. With the SIG in place,
the biggest current pain points for etcd update in k8s are:
- undocumented, manual image promotion process.
- no dedicated top level approver to own etcd k/k updates as it touches a lot of things.
- too many steps, different repos, client vs server updates
kubeadm updates are simple - changing a small version map / constant. by updating kubeadm k8s+etcd gains upgrade signal from etcd version at k8s N-1 to etcd version at k8s N. the kube-up upgrade suite is still not working, IIRC.
I think we can discuss changing/improving the release process.
happy to participate.
Do we need all votes or just quorum is enough? FYI etcd community does things by quorum :P |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, with one non-blocking call out
@serathius The Kubernetes Steering Committee normally gives opportunities for all seven of us to weigh in on a subject wherever possible as ideas/changes/etc are improved by the diversity of perspectives and inputs. We will sometimes push through small changes with 1 person or a simple majority signing off, but establishment of a new SIG is one of those things where we will try to let everyone chime in. |
/lgtm |
can unhold? |
Not yet. I was reapplying an LGTM after a minor change (updating zoom link). We will likely remove the hold on Monday when the SC meets. |
@cblecker Thanks Christoph, do we need someone from etcd to attend the SC meeting to answer questions if there is any? |
@wenjiaswe It is a public meeting so you're welcome to attend, however I don't think it'll be required. I, at least, don't have any outstanding questions. |
/lgtm |
/lgtm We can set the liaison subsequently. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
/lgtm
/approve (Steering)
As we have unanimous support from @kubernetes/steering-committee, I'm lifting the hold on this.
Welcome SIG etcd!
/hold cancel
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: BenTheElder, cblecker, justaugustus, logicalhan, palnabarun 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 |
approvers: | ||
- sig-etcd-leads | ||
labels: | ||
- sig/etcd |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is this label ready?
@pacoxu: The label(s) sig/etcd cannot be applied, because the repository doesn't have them.
kubernetes/kubernetes#118077 (comment)
Currently, we have area/etcd
label.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for reminding, this is done now: kubernetes/test-infra#30948
FTR, @cici37 added the |
Setting up SIG-etcd.