-
Notifications
You must be signed in to change notification settings - Fork 9.8k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
RFC: StoreV2 deprecation plan #12913
Comments
Thanks for helping with this! (I wanted to have a clean separation between v2 and v3 a couple of years ago but never got time actually to do it). I am not sure if we are still running the failure injection tests. I would suggest running them to ensure the correctness of this change. Also, we might want more tests on the membership changes and the upgrade path. /cc @gyuho |
@xiang90 |
The functional test randomly injects failures into the running servers. Due to the randomness, it might not be super effective to catch issues if it only runs one round in the CI. What we did previously was to run this test 24*7 for weeks on a set of servers before major releases. I am not sure if it is still the practice since we have not really introduced significant changes to etcd in the recent releases I believe. |
@ptabor This looks great. Regarding
as we discussed, let's mark it as deprecated for 3.5 and remove for 3.6. Then, there's no need for
? |
We do run functional tests with failure injection in the CI but haven't implemented member add/remove ref. etcd/tests/functional/functional.yaml Lines 174 to 195 in 6decbe1
|
Flags `--experimental-enable-v2v3` and '-enable-v2' will raise a warning in 3.5, in 3.6 they are schedule for decomissioning, such that v2store can stop be written in 3.7. Deprecation plan in: etcd-io#12913
Flags `--experimental-enable-v2v3` and '-enable-v2' will raise a warning in 3.5, in 3.6 they are schedule for decomissioning, such that v2store can stop be written in 3.7. Deprecation plan in: etcd-io#12913
Flags `--experimental-enable-v2v3` and '-enable-v2' will raise a warning in 3.5, in 3.6 they are schedule for decomissioning, such that v2store can stop be written in 3.7. Deprecation plan in: etcd-io#12913
Flags `--experimental-enable-v2v3` and '-enable-v2' will raise a warning in 3.5, in 3.6 they are schedule for decomissioning, such that v2store can stop be written in 3.7. Deprecation plan in: etcd-io#12913
Flags `--experimental-enable-v2v3` and '-enable-v2' will raise a warning in 3.5, in 3.6 they are schedule for decomissioning, such that v2store can stop be written in 3.7. Deprecation plan in: etcd-io#12913
I hope/think mandatory steps for v3.5 are done. |
Flags `--experimental-enable-v2v3` and '-enable-v2' will raise a warning in 3.5, in 3.6 they are schedule for decomissioning, such that v2store can stop be written in 3.7. Deprecation plan in: etcd-io#12913
This issue has been automatically marked as stale because it has not had recent activity. It will be closed after 21 days if no further activity occurs. Thank you for your contributions. |
Nice summary. @geetasg
The detailed plan seems not in sync with the summary above, and isn't clear to me either. I think roughly what we need to do in 3.6 are (on top of both @serathius 's summary and your summary in the above doc) :
|
@ahrtr Thank you for the review. This poc is at branch poc1 in my repo. |
Also listing the plan for other items - Currently this work is on #1 - PR is being discussed.. |
Plan for V2 apply code is removed - v2v3 applier can be removed once the 3.5 publish node request is n/a. |
|
@ahrtr @serathius @ptabor please let me know if you have any questions/comments on the plan listed above. These changes are poced in #16000. Thanks |
Overall looks good to me, let's do it step by step. |
@geetasg Could you summarize all remaining tasks in one comment using a hierarchical structure to clearly show what has been completed and what has not? thx |
@ahrtr updated #12913 (comment) above to indicate latest status. In terms of high level tasks as listed in Plan section above for 3.6 release -
|
Starting 3.4, default API for etcdctl commands is v3. But v2 is still supported and extensively used in 3.4. (source: etcd-io/etcd#12913) Although it is a better idea to use v3 at as much places in the code as possible, in case of cluster health API, v2 API gives more clearer error about bad certificate usage than v3. So it is better to stick to v2 than v3 at least in this case. An environment variable ETCDCTL_API is used to specify the usage of non-default version. A prefix for v2 API usage is added to the only occurence of 'etcdctl' in the /etc/init.d/etcd script. Test Plan: PASS: Run '/etc/init.d/etcd status' with correct pair of certs. Etcd status is 'Running'. PASS: Run '/etc/init.d/etcd status' with incorrect pair of certs. Etcd status is 'Running'. Story: 2010878 Task: 48960 Change-Id: Idaaecfeec2c4851b4e33c21839df12cea5a65c2e Signed-off-by: Kaustubh Dhokte <[email protected]>
[The content of this post is being edited, and is not yet approved plan of record ]
Background
In 3.4 storeV2 is still extensively used:
User can opt in
--enable-v2
to unable V2 API that writes solely data to storeV2 files.Membership information is both stored in V2 & V3 (backend) stores
Membership information is being read (recovered) from storeV2
Publishing membership happens through StoreV2 raft operation.
During startup etcd assumes each WAL log snapshot is accompanied by storev2 snapshot.
Note:
etcdctl snapshot restore
is not restoring V2 content (producing fake storeV2 with membership information)Plan:
3.5 release (updated by ahrtr )
Both V2 and V3 state are supported, but V3 becomes the source of truth. TODO:
--enable-v2v3=...
or deprecated. [see https://github.com/3.5 decision making for alpha/beta/experimental feature stability #12905]--enable-v2v3=...
]--enable-v2
is ONits validated whether it has no used-data (apart of membership & version)
3.6 release (updated by serathius@, ahrtr )
V3 is the only meaningful state. V2 state is generated from V3 state to maintained backward compability. TODO:
--enable-v2
is docomissionedV2 no longer stores membership data--v2-deprecation
#18994--snapshot-count
as deprecated and to be decommissioned in 3.7 #189953.7 release (updated by serathius@, ahrtr )
--v2-deprecation
to V2Depr1WriteOnlyDrop3.8 release
Remove
--v2-deprecation
. Completely cleanup anything related to v2store.Docs
https://docs.google.com/document/d/1dpvBrOvBquZ8QozJcT6xcwVUVXYwO3hvjmVBd7ixIJU/editThe text was updated successfully, but these errors were encountered: