Feature Description
There is a good reason we never exposed the embedded etcd: Safety. We wanted to be opinionated and guide users towards a sane, stable kcp installation.
Howeeeeeeeever it's really tedious to have to setup an etcd everytime I want to test any other piece of software against kcp[-operator]. Like the init-agent. For these cases I really, really do not care about persistence and would actually welcome the ability to quickly wipe my state and start fresh by simply deleting the kcp pod. Yet I want to use the kcp-operator because I am testing/documenting how its Kubeconfig RBAC feature can be used for the init-agent. And I suspect many more people will be in the same boat.
Proposed Solution
Do expose an option for enabling the embedded etcd in a kcp shard. The data should always be on an emptyDir volume, i.e. be ephemeral. There should be no option to change the volume, since we really do not want to have folks running the embedded etcd with persistence. That is truly reinventing what an external etcd already does much better.
The option in our CRDs should have a big warning that informs the users about the downsides.
The CRD should also contain validation to prevent replicas>1 when embedded etcd is enabled.
Alternative Solutions
No response
Want to contribute?
Additional Context
No response
Feature Description
There is a good reason we never exposed the embedded etcd: Safety. We wanted to be opinionated and guide users towards a sane, stable kcp installation.
Howeeeeeeeever it's really tedious to have to setup an etcd everytime I want to test any other piece of software against kcp[-operator]. Like the init-agent. For these cases I really, really do not care about persistence and would actually welcome the ability to quickly wipe my state and start fresh by simply deleting the kcp pod. Yet I want to use the kcp-operator because I am testing/documenting how its Kubeconfig RBAC feature can be used for the init-agent. And I suspect many more people will be in the same boat.
Proposed Solution
Do expose an option for enabling the embedded etcd in a kcp shard. The data should always be on an emptyDir volume, i.e. be ephemeral. There should be no option to change the volume, since we really do not want to have folks running the embedded etcd with persistence. That is truly reinventing what an external etcd already does much better.
The option in our CRDs should have a big warning that informs the users about the downsides.
The CRD should also contain validation to prevent replicas>1 when embedded etcd is enabled.
Alternative Solutions
No response
Want to contribute?
Additional Context
No response