Donate etcd operator to sig-etcd and unify community effort

[kvaps]

What would you like to be added?

Hi, at Ænix we have organized a group of enthusiasts from Russian-speaking Kubernetes comunity on writing a generic etcd-operator.

We decided to donate this project to SIG's to make it more standartized and generic solution. We aim to create a universal tool that meets the needs of every adopter. And that's why we are here at such an early phase of development.

Right now the project is located here: https://github.com/aenix-io/etcd-operator

In Kubernetes community we already agreed, that community need official etcd-operator and placing it under sig-etcd. However the sig-etcd still has to choose which operator they want to use as a basis, ours or some other one.

This ubrela-issue created to track process for adopting etcd-operator, and all related issues connected to this.

Original slack thread: https://kubernetes.slack.com/archives/C3HD8ARJ5/p1711138820558879

All related issues and PRs:

• https://github.com/cncf/sandbox/issues/91
• https://github.com/kubernetes/community/pull/7796
• https://github.com/kubernetes/org/pull/4839
• https://github.com/kubernetes/website/pull/45644
• https://github.com/aenix-io/etcd-operator/issues/73

Why is this needed?

Many projects require the opportunity to run etcd clusters in Kubernetes easily. Potencial adopters, such projects as:

• Cozystack
• Cilium
• Mayastor
• Vitastor
• Kamaji
• Stolon
• Patroni
• Goteleport
• LINSTOR
• Gardner

[serathius]

Thanks for the issue, as you mentioned community hit the critical mass and we want to adopt an official operator. However, it looks like this happened in multiple different groups, so my goal is to gather everyone interested to discuss it.

Creating something from scratch is great to get people excited, but we need to make sure that the solution we pick is adapted by community so it can be sustainable long term vs all previous attempts of etcd-operators that were abandoned. There are a lot of companies that are developing their own forks of etcd operator and we need to make sure that we invite them to participate and make it easy for them to adopt.

cc @marseel from Cillium cc @mvisonneau @hemanthmalla from DataDog

[jmhbnz]

/retitle Donate etcd operator to sig-etcd and unify community development effort

[ahrtr]

/retitle Donate etcd operator to sig-etcd and unify community development effort

We can

• either adopt an existing etcd-operator, then evolve on top of it.
• [most likely personally thought] or create a new one, but refer to or reuse some implementation of existing projects (e.g. etcd-manager, coreos/etcd-operator )
  • I will evaluate both etcd-manager and coreos/etcd-operator, and also reference kubernetes/sample-controller

Either way, eventually we will have a sub-project github.com/etcd-io/etcd-operator under sig-etcd; and setup a dedicate list of maintainers to maintain the sub-project.

[kvaps]

I think we have to establish a working group that includes developers from other etcd-operators and leverage their expertise to design a new operator. This design will then be utilized to develop a new, enhanced solution under the leadership of sig-etcd. Of course some code can be reused.

We're in the early phase of development right now, which allows us to be flexible and accommodate everyone's requirements.

[jmhbnz]

Update: Closing this issue as the etcd operator working group is now in place and the development of a revitalized officially supported operator for etcd is now underway in http://github.com/etcd-io/etcd-operator.

Many thanks to everyone who has helped highlight the need, responded to our user survey and provided input to the working group so far. For anyone who would like to get involved further we invite & welcome your contributions towards etcd-io/etcd-operator 🙏🏻