-
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
use v2 api to update cluster version #12988
Conversation
@@ -2484,6 +2485,46 @@ func (s *EtcdServer) updateClusterVersion(ver string) { | |||
) | |||
} | |||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Might as well rename this method to updateClusterVersionV2
, to be clear?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can we also update the logging
"updating cluster version using v2 API
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"setting up initial cluster version using v2 API"
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Added in the next revision as your comments. PTAL @gyuho
server/etcdserver/server.go
Outdated
|
||
if s.cluster.Version() == nil { | ||
lg.Info( | ||
"setting up initial cluster version", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... using v3 API
server/etcdserver/server.go
Outdated
) | ||
} else { | ||
lg.Info( | ||
"updating cluster version", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
... using v3 API
63e1a2a
to
8e9b77a
Compare
I wonder how apply V2 is working. This lines worry me: etcd/server/etcdserver/apply_v2.go Lines 95 to 99 in e73facb
looks like neither write to v2 store nor v3 store, or I'm missing something. etcd/server/etcdserver/api/membership/cluster.go Lines 256 to 262 in e73facb
|
Think the contributor of https://github.com/etcd-io/etcd/pull/11427/files?file-filters%5B%5D=.go#diff-2a81e175edbcc322a52051676dc08cb497741e608dbefa4ac67d8e042cd902ccL94-L99 removed the v2 apply to store cluster version and added to v3 api. I just revert back her change. |
Codecov Report
@@ Coverage Diff @@
## main #12988 +/- ##
===========================================
- Coverage 68.83% 52.42% -16.41%
===========================================
Files 442 419 -23
Lines 34105 32753 -1352
===========================================
- Hits 23477 17172 -6305
- Misses 8709 13812 +5103
+ Partials 1919 1769 -150
Flags with carried forward coverage won't be shown. Click here to find out more.
Continue to review full report at Codecov.
|
Looks like we just return empty response, because there's no really consumer of this response given it's an internal API. This change looks good to me. Any other concern? |
/cc @YoyinZyc |
The actual storeV2 set happens in line 100. If we return in line 98, how do we store the value ? etcd/server/etcdserver/apply_v2.go Line 100 in e73facb
|
@ptabor In release 3.4, we don't call
I believe that was the motivation we are migrating to v3 API for everything, right? v2 cluster state as it is now is not persistent. Unfortunately, those migration effort made some breaking changes. For reference, this is release-3.4 branch: Lines 95 to 102 in d19fbe5
|
Thanks. I missed that:
|
During review of: etcd-io#12988 spotted that PUT is actially writing to v3-backend. If we are replaying WAL log, it might happened that backend's applied_index is > than the WAL's log entry. In such situation we should skip applying on backend V3. I think both the methods (setVersion, setMembersAttributes) are in practice idempotent so its not that 'serious' problem, but for formal correctness adding the proper checks.
During review of: etcd-io#12988 spotted that PUT is actially writing to v3-backend. If we are replaying WAL log, it might happened that backend's applied_index is > than the WAL's log entry. In such situation we should skip applying on backend V3. I think both the methods (setVersion, setMembersAttributes) are in practice idempotent so its not that 'serious' problem, but for formal correctness adding the proper checks.
During review of: etcd-io#12988 spotted that PUT is actially writing to v3-backend. If we are replaying WAL log, it might happened that backend's applied_index is > than the WAL's log entry. In such situation we should skip applying on backend V3. I think both the methods (setVersion, setMembersAttributes) are in practice idempotent so its not that 'serious' problem, but for formal correctness adding the proper checks.
How to enable the downgrade by API, could you please share an example?@chaochn47 Does v3.5.0 already support this functionality? |
Fix #12987
Testing cluster version upgrade from 3.4 to 3.5
Testing cluster version downgrade from 3.5 to 3.4