etcd Operator Requirements and Use Cases Survey

[Benjamin Wang]

Hello,

We (both sig-etcd and sig-cluster-lifecyle) are planning to develop an official etcd-operator. This operator is specifically for people who run etcd clusters in addition to the one embedded in Kubernetes. In the first step, we'd like to collect feedback from the community. Please kindly fill in the following survey when you get a couple of minutes. Thanks.

https://forms.gle/5gBpzaxYtuQPWdBo9

Regards,

Benjamin

[James]

I really think this is a bad idea. Please correct any assumptions that
I got wrong:

operator depends on k8s
k8s depends on etcd
etcd gets managed by operator

You have a loop. Things will end badly.

Put another way: you want to use a centralized automation tool
(operators) to manage a distributed system. It really makes no sense.

Disclosure, I'm biased because I'm trying to build distributed
automation tech in https://github.com/purpleidea/mgmt/
But I think what I'm saying has merit.

There are two ways to solve the etcd automation problem:

1) Build it into the etcd core. I have a prototype of how this would
work in https://github.com/purpleidea/mgmt/tree/master/etcd
To be quite honest, I wouldn't use or trust most of that code as-is. I
wrote it before I was very proficient with golang concurrency, but it
has roughly the right idea and could be improved if someone wanted to
invest the time. This would probably benefit from this feature:
https://github.com/etcd-io/etcd/issues/5277 (eight years ago!)

2) Build it in the mgmt `mcl` language itself. This is doable, and I
plan to do this eventually. Sooner if someone wants to sponsor the
work.

And lastly, please put time towards fixing important issues in etcd,
before we invest it into having bigger problems with operator.
Embarrassingly important bugs are just killed by the stale bot, eg:
https://github.com/etcd-io/etcd/issues/10566 (five years ago!)

HTH,
James

> --
> You received this message because you are subscribed to the Google Groups "etcd-dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to etcd-dev+u...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/etcd-dev/c6371394-a00a-4b2e-b265-5d4b1f696353n%40googlegroups.com.

[张-]

Hi

The project sounds great, do we have any milestone plans for developing this operator? Should we build it from scratch ,or should we adopt an existing project?  We（datebase reseach group in HUST）would like to do some contributions for this  new project.

[Lan Liang]

have some discussion at here https://github.com/etcd-io/etcd/issues/17668

[Benjamin Wang]

Thanks for the feedbacks.

Please note that the etcd-operataor manages etcd cluster running in Kubernetes environment to support applications instead of Kubernetes itself. We also clarified it on top of the survey. It's the very beginning phase, the detailed plan & roadmap haven't finalized yet. Any contribution is definitely welcome!

[Josh Berkus]

On 5/14/24 18:32, 张- wrote:
> The project sounds great, do we have any milestone plans for developing
> this operator? Should we build it from scratch ,or should we adopt an
> existing project?  We（datebase reseach group in HUST）would like to do
> some contributions for this  new project.

My personal thinking is: start over from scratch, using kubebuilder and
modern tools.

The original operator was created for Kubernetes v1.3.

--
-- Josh Berkus
Kubernetes Community Architect
OSPO, OCTO