etcd-operator adoption

[kvaps]

Hey, I know that LINSTOR might use etcd for storing metadata. While the main method now is Kubernetes CRDs I'd like to inform you that we've initiated a group effort to create a generic, multi-purpose etcd-operator. Currently, the project is in its early development phase, so there's a good opportunity for you to make influence on the project.

https://github.com/aenix-io/etcd-operator

Our development process is open, and we are in discussions with sig-etcd about the possibility of making this the official version under Kubernetes-SIGs. Our goal is to bring together all potential adopters.

We would be pleased if you could present your official stance on this initiative and respond to the following questions:

• Whether your project requires an etcd-operator at all.
• Would you like to adopt and start using it once a stable version is released?
• How important is it to you that the project continues to develop under the control of the official sig-etcd?
• Would you be interested in joining the development and discussions to help address architectural challenges?

We welcome any other ideas and suggestions you have regarding this initiative.

[WanzenBug]

Hey! Great to see someone picking up on this! This always seemed like a missing part of the k8s eco-system when the old operator was abandoned.

To answer your questions:

Whether your project requires an etcd-operator at all.

It used to, in the past. Since we where unhappy with users having to maintain a separate etcd instance just for LINSTOR, we eventually moved to storing data in the custom resources in the kubernetes API. While it is still possible to use the Etcd backend, we would like to move every on to alternatives.

Would you like to adopt and start using it once a stable version is released?

As mentioned, we have actively worked on an alternative, specifically so we no longer have to use Etcd. This was originally motived by reducing the maintenance burden, as we used to maintain a fork of an etcd deployment chart with specific fixes. This also meant we were "responsible" for this etcd, should something go wrong. With a community-supported etcd-operator this would no longer be needed.

The second issue is that for LINSTORs purposes, etcd is just not a good fit, apart from being some version of "highly available". This made it even more attractive for us to move on.

How important is it to you that the project continues to develop under the control of the official sig-etcd?

We were surprised that there was no community driven effort already. While we no longer have a use for it, we feel this is an important part of the ecosystem that is still missing.

Would you be interested in joining the development and discussions to help address architectural challenges?

We can certainly share our findings and troubles with maintaining etcd, without having the resource to actively build or even test any new developments.