kubernetes
etcd operator working group
Initial PR to create wg-etcd-operator.
/committee steering
Adding stakeholder SIGs
/sig etcd /sig cluster-lifecycle
cc @jmhbnz @jberkus @serathius @wenjiaswe @fabriziopandini @hakman @neolit123 @justinsb @vincepri
We need to finalize:
- liaison
- day/time for the regular meeting
- zoom link for the meeting
- a google doc (archive_url)
- slack channel
- mailing list url
LGTM, awesome to see renewed interest into etcd-operator. For me this falls into making "etcd simple to operate" as proposed by the SIG-etcd vision making it a worthy investment.
/hold
I am going to send an email "WG-Creation-Request: WG etcd-operator" to [email protected] in the following 1~2 weeks.
Hi! The aenix's etcd-operator team is here.
We have multiple regular contributors to the project and weekly meetings established. We would like to participate in this project and are open to donating our etcd-operator code here (if applicable)
We started this initiative to write a fully community-driven etcd-operator a few months ago and informed sig-etcd about our intention. I am surprised that nobody mentioned us in this issue.
Related issues:
- https://github.com/kubernetes/community/pull/7796#issue-2215254797
- https://github.com/etcd-io/etcd/issues/17668
How can we ensure this process will not run without our team?
/cc @sircthulhu @aobort @sergeyshevch @lllamnyp @Kirill-Garbar @Uburro
@kvaps: GitHub didn't allow me to request PR reviews from the following users: lllamnyp, Kirill-Garbar, Uburro, sircthulhu, aobort.
Note that only kubernetes members and repo collaborators can review this PR, and authors cannot review their own PRs.
In response to this:
Hi! The aenix's etcd-operator team is here.
We have weekly meetings established and multiple regular contributors to the project. We would like to participate in this project and are open to donating our etcd-operator code here.
We started this initiative to write a fully community-driven etcd-operator a few months ago and informed sig-etcd about our intention. I am surprised that nobody mentioned us in this issue.
Related issues:
- https://github.com/kubernetes/community/pull/7796#issue-2215254797
- https://github.com/etcd-io/etcd/issues/17668
How can we ensure this process will not run without our team?
/cc @sircthulhu @aobort @sergeyshevch @lllamnyp @Kirill-Garbar @Uburro
Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes-sigs/prow repository.
Hi! The aenix's etcd-operator team is here.
We have multiple regular contributors to the project and weekly meetings established. We would like to participate in this project and are open to donating our etcd-operator code here (if applicable)
We started this initiative to write a fully community-driven etcd-operator a few months ago and informed sig-etcd about our intention. I am surprised that nobody mentioned us in this issue.
Related issues:
- Add etcd-operator subproject to etcd-io #7796 (comment)
- Donate etcd operator to sig-etcd and unify community effort etcd-io/etcd#17668
How can we ensure this process will not run without our team?
/cc @sircthulhu @aobort @sergeyshevch @lllamnyp @Kirill-Garbar @Uburro
As mentioned in https://github.com/kubernetes/community/pull/7917#discussion_r1642443076, anyone is welcome to participate, we definitely need community help on this project.
Regarding the decision to pick an existing project or start from scratch, it's up to sig-etcd and sig-cluster-lifecycle leads. Please note that even if we decide to start from scratch, we will most likely refer to some existing implementations, such as etcd-manager.
@ahrtr thank you. Is there any planned schedule or meeting regarding this project?
@ahrtr thank you. Is there any planned schedule or meeting regarding this project?
We need to wait for the Kubernetes Steering Committee to approve the WG creation request. Once we get approval, we will have regular WG Meeting, e.g bi-weekly.
We need to wait for the Kubernetes Steering Committee to approve the WG creation request. Once we get approval, we will have regular WG Meeting, e.g bi-weekly.
Got it! Thank you for the information :)
I learnt many projects are using etcd operators for performance issues. A simple solution is using a seperate etcd.
- kyverno has a new project for report server to save reports in a seperate etcd： https://github.com/kyverno/reports-server @realshuting
- Cilium has a solution of using a seperate etcd for all CRDs: @aanm https://github.com/cilium/cilium-etcd-operator is archived.
- other scanerios like Events and more. @kvaps has a longer list in https://github.com/aenix-io/etcd-operator/issues/73
Those projects' maintainers and users are potential etcd operator contributors and users.
It would be great if they can at least response to our survey in https://forms.gle/5gBpzaxYtuQPWdBo9.
@pacoxu
It would be great if they can at least response to our survey in https://forms.gle/5gBpzaxYtuQPWdBo9.
do you see this as a blocker for the WG etcd operator creation?
steering committee met on July 3rd but the creation of this WG was not on the agenda. in terms of the punch card here: https://github.com/kubernetes/community/blob/master/sig-wg-lifecycle.md#prerequisites-for-a-wg
we are all set with the exception of:
- steering majority / voting on this ticket
- ~sending PR for sigs.yaml in k/community~ EDIT: nvm, this PR does that.
- ~sending email about the sigs.yaml change~ EDIT: we can just forward the below email
email was already sent to k-dev: https://groups.google.com/a/kubernetes.io/g/dev/c/L1TgHxIkW_o
Hey I just wanted to inform that we have weekly comunity meetings for developing aenix-io/etcd-operator, we'll have one of these tomorrow:
When: every Tuesday at 16:00 CET Where: Google meet Link to join in: https://meet.google.com/pib-tpfe-kuv
Minutes: https://docs.google.com/document/d/1coiWlHOVfPAIyKqtfpYLhq9eeRPHCuuMxmNmVfo9-sA/edit
Everybody is free to join
I learnt many projects are using etcd operators for performance issues. A simple solution is using a seperate etcd.
* kyverno has a new project for report server to save reports in a seperate etcd： https://github.com/kyverno/reports-server @realshuting * Cilium has a solution of using a seperate etcd for all CRDs: @aanm https://github.com/cilium/cilium-etcd-operator is archived. * other scanerios like Events and more. @kvaps has a longer list in [[epic] Move project to Kubernetes-SIGs aenix-io/etcd-operator#73](https://github.com/aenix-io/etcd-operator/issues/73)Those projects' maintainers and users are potential etcd operator contributors and users.
I believe this point:
Bootstrap a project "etcd-operator" owned by SIG etcd which resides in the etcd-io or kubernetes-sigs Github orgs.
- Review existing etcd operators to see if any could be forked or referenced to advance the project.
can be considered as covering Paco's comment. I don't think we want to explicitly mention these projects in the charter.
/lgtm /approve （steering）
@pacoxu It would be great if they can at least response to our survey in https://forms.gle/5gBpzaxYtuQPWdBo9.
do you see this as a blocker for the WG etcd operator creation?
just want to make more cloud native contributors/maintainers/users know this new wg and participate
[APPROVALNOTIFIER] This PR is APPROVED
This pull-request has been approved by: ahrtr, BenTheElder, kvaps, pacoxu, palnabarun, soltysh
The full list of commands accepted by this bot can be found here.
The pull request process is described here
- ~~OWNERS~~ [BenTheElder,pacoxu,palnabarun,soltysh]
Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment
/hold cancel thank you everyone for commenting. (4 steering votes were added)