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.