This repository has been archived by the owner on Mar 28, 2020. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 741
etcd2 backup/restore support in operator #1123
Comments
I remembered the plan is to use v2 API proxy on top of etcd3. Is there any tracking issue? @xiang90 @heyitsanthony |
Any updates on this? |
i do not think etcd operator will ever deal with a v2 data snapshot. one option is the make etcd itself to support v2 api with v3 data. |
@xiang90 @heyitsanthony Is there an issue that is being tracked in etcd? |
@hongchaodeng Thanks, awesome! |
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
@xiang90 @philips @heyitsanthony
etcd-operator is awesome and we are really excited to use this in production.
Our usecase is Here and we are using etcd as vault backend on kubernetes. So now comes the real requirement of highly available with auto pilot (operator)
Not having v2 is stopping us from using it. We were early adopters of etcdv2 and have clients using it and they cant/didnt migrate to v3 yet. One of the limitations being no java client library available and moving away from rest to grpc made it not so easy for clients to start using v3. The cluster is already running 3.1
No doubt that v3 is awesome but can't force clients to move to v3. Is it a lot of work to have v2 back/restore as part of operator too.
I see that this was reported earlier #864 and I'm pretty sure that there must be many who want to use operator and not having v2 backup/restore might be a limitation. This supports only new users who are starting to use v3.
The only option I see is to have a side car container running which should reinitialize v2 data from a backup that it had taken before. (not an ideal way of doing it though)
The text was updated successfully, but these errors were encountered: