Add etcd-operator subproject to etcd-io

[kvaps]

Hey everyone,

We've established a community to develop a unified etcd-operator. This project is entirely community-driven and currently comprises mainly members of the Russian-speaking Kubernetes community. Although we've just begun, there's already significant activity, with approximately 10 active developers onboard.

We want two things:

1. To donate this project to CNCF:
   • [Sandbox] etcd-operator cncf/sandbox#91
2. Get a place under kubernetes-sigs:
   • Add etcd-operator subproject to etcd-io #7796
   • Add maintainers-etcd-operator to etcd-io org org#4839

[kvaps]

/assign @cblecker

[jmhbnz]

Link to discussion in kubernetes slack #sig-etcd https://kubernetes.slack.com/archives/C3HD8ARJ5/p1711138820558879 for awareness.

[cblecker]

Hello @kvaps !

This item needs some further discussion. Becoming a CNCF Sandbox project, or a subproject of a SIG (either Cluster Lifecycle or etcd) are mutually exclusive goals. CNCF Sandbox projects are independently governed projects, while subprojects of SIGs are housed under the auspices of the Kubernetes project itself and are subject to the governance processes of the Kubernetes project itself.

I see there is a link to a thread where you are discussing this with sig-etcd, which I think is a great start. Have you discussed this at all with SIG Cluster Lifecycle? I think you should pull folks from these groups together in order to discuss where you want to house this.

The process for donating repos to the Kubernetes project is outlined here: https://github.com/kubernetes/community/blob/master/github-management/kubernetes-repositories.md#rules-for-donated-repositories

That said, if you want this to be an independently governed project in the CNCF sandbox, that is a completely separate process.

Until those conversations happen and some decisions have been made around where the best place to host this are, I'm putting these requests on hold. I would also note that as KubeCon EU just wrapped up, some folks might be slow to respond as they may be travelling and catching up.

/sig etcd cluster-lifecycle
/committee steering
/hold

[kvaps]

Hi @cblecker thanks for explanation, I’ll take a look into the documentation and update the PR accroding to it.

Have you discussed this at all with SIG Cluster Lifecycle?

Not yet, I’ve just copied the configuration for etcdadm repository which included in #sig-cluster-lifecycle. #sig-etcd has expressed a potential interest in sponsoring the project, but now I’m thinking that #sig-cloud-provider would be more suitable for this project.

/sig sig-cloud-provider

[k8s-ci-robot]

@kvaps: The label(s) sig/sig-cloud-provider cannot be applied, because the repository doesn't have them.

In response to this:

Hi @cblecker thanks for explanation, I’ll take a look into the documentation and update the PR accroding to it.

Have you discussed this at all with SIG Cluster Lifecycle?

Not yet, I’ve just copied the configuration for etcdadm that’s included in #sig-cluster-lifecycle, #sig-etcd has expressed a potential interest in sponsoring the project, but now I’m thinking that #sig-cloud-provider would be more suitable for this project.

/sig sig-cloud-provider

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/test-infra repository.

[kvaps]

/sig cloud-provider

[kvaps]

Okay, I withdrew my application to join the CNCF sandbox and informed the sig-cloud-provider in slack about our proposal.

@cblecker just fyi

[neolit123]

@kvaps

in SIG cluster lifecycle we have etcdadm, but now that we have SIG etcd IMO all etcd* related bits should be under them.
SIG Cloud provider seems unrelated to an etcd operator.

currently no SIG charters mention etcd lifecycle management, as they are AFAIK.
happy to discuss during a zoom call too.

/hold
hold until the target owner is clear and leads have singed in this thread.

[serathius]

Maybe let me share in more detail on what happened during KubeCon. We have agreed that the etcd community needs an official operator and we will create a document that specifies requirements and options we have on either adopting something existing or bootstrapping a new one.

I share some of @ahrtr concerns (from slack discussion on #sig-etcd) about this etcd-operator being pretty new. However I don't have any strong opinions on which etcd-operator we should pick.
My goal is to ensure that we don't miss anyone's voice when making the decision and provide necessary etcd expertise from etcd maintainers.

I understand that there are already existing etcd management projects in sig-cluster-lifecycle, however I can't speak to their production readiness as those communities never really reached out to the etcd community. My first thought would be to put the operator in etcd project to make sure it can take advantage of our expertise.

[neolit123]

I share some of @ahrtr concerns (from slack discussion on #sig-etcd) about this etcd-operator being pretty new. However I don't have any strong opinions on which etcd-operator we should pick.
My goal is to ensure that we don't miss anyone's voice when making the decision and provide necessary etcd expertise from etcd maintainers.

oh, so https://github.com/aenix-io/etcd-operator is a new operator.
i was thinking https://github.com/coreos/etcd-operator which is a mature project.

with such a conflict of interest it feels like this topic really should be under the sig etcd expertise.

I understand that there are already existing etcd management projects in sig-cluster-lifecycle, however I can't speak to their production readiness as those communities never really reached out to the etcd community. My first thought would be to put the operator in etcd project to make sure it can take advantage of our expertise.

that would be https://github.com/kubernetes-sigs/etcdadm
and if sig etcd adapts its charter to include etcd lifecycle management tools such as operators, sig cl could propose to sig etcd to migrate the etcdadm project to sig etcd.

i think now that we have the specialized SIG, etcdadm is better suited for a new home. but that's a separate discussion.
@justinsb @hakman @srikiz CC for etcdadm

[fabriziopandini]

in SIG cluster lifecycle we have etcdadm, but now that we have SIG etcd IMO all etcd* related bits should be under them.

This seems the best way forward also for me, but happy to chat about it if necessary

[kvaps]

yes, let's close existing PRs for SIG CL or adapt them for SIG etcd.

I rebased this PR to refer sig-etcd instead.

@kvaps ideally subproject proposals happen during a Zoom call or on a mailing list
https://github.com/kubernetes/community/blob/master/sig-etcd/README.md

Sure, I informed the team, we will come tomorrow at sig-etcd meeting

[serathius]

Sure, I informed the team, we will come tomorrow at sig-etcd meeting

The tomorrows sig-etcd meeting is not a normal meeting, it's a triage meeting. Meaning it's not for discussion, it's for reading through issues and assigning them to contributors. The both meetings run bi-weekly sharing the same spot. Please consider joining the following week.

Please start from opening an umbrella issue in https://github.com/etcd-io/etcd to merge all the discussion. The etcd community wants to introduce a etcd-operator, but we haven't decided on which one. We are discussion with Datadog on open sourcing their operator. We need single forum for everyone to gather and be heard.

[kvaps]

@serathius ok thanks, I created this issue etcd-io/etcd#17668

[bsctl]

@kvaps thanks for the great work. An etcd-operator is the missing piece as this landscape looks fragmented. Your work looks promising and we can consider to adopt it once it becomes stable.

[Bo0km4n]

@kvaps
This is so good proposal for me.
Especially, I strongly agree this your statement.

Right now it is intended to run etcd in ready Kubernetes cluster to bootstrap other tenant Kubernetes control-planes.
This is useful for providing Kubernetes-as-a-service, eg. projects like Kamaji, Cozystack and HyperShift and some other projects which use etcd for storing their metadata, eg. cilium, mayastor, vitastor and so on.

openshift/etcd-operator is already exists, but I think we can't use this operator on the plane Kubernetes cluster.

[serathius]

My recommendation from the etcd community meeting on April 4th where this proposal was discussed:

There is an interest having a etcd-operator, not necessarily one proposed here.

We are happy to see the initiative by Ænix, but the community shouldn't feel forced to adopt this one. Adoption to SIG-etcd should be done because the solution is embraced by community, not because we think it would be nice for community to adopt it.

To feel comfortable to adopt the project I would like to see that:

• Project is embraced by community - contributors and maintainers are coming from diverse set of companies and we see sustainable contributions.
• Project is embraced by users - we have usage by companies outside of maintainers. User feedback is included in project planning.
• Project shows signs of maturity - API is Beta stability, it was reviewed by experts and we don't expect to break it immediately. It's stable enough for companies outside of core maintainers to start considering it for production use.

Etcd maintainers will continue the effort to introduce a official etcd-operator, with the one proposed here as one of the candidates.

[ahrtr]

Etcd maintainers will continue the effort to introduce a official etcd-operator, with the one proposed here as one of the candidates.

Yes, I am evaluating some of the existing etcd operators, and will share it with the community in the following 1~2 weeks. etcd maintainers will discuss & coordinate & drive the effort.

EDIT: also share my previous comment here: etcd-io/etcd#17668 (comment)

[cblecker]

@serathius Where would be the right place for interested folks to coordinate with the SIG on those efforts? I'm concerned this open PR is probably not the right place. Would it be etcd-io/etcd#17668 perhaps?

[ahrtr]

Would it be etcd-io/etcd#17668 perhaps?

I think so. We should have only one place for all discussion, let's continue all the following discussion in etcd-io/etcd#17668.

We may send email to etcd-dev or draft google doc to collect feedback later, also raise meetings to collect all interested folks.

[cblecker]

@ahrtr Sounds great!

@kvaps Thanks for engaging with us! I'm going to close this PR for now so that the discussion focuses in etcd-io/etcd#17668 . Once a decision is made, this or a subsequent PR can be opened.

[cblecker]

/close

[k8s-ci-robot]

@cblecker: Closed this PR.

In response to this:

/close

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/test-infra repository.