-
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
support seamless rollback 1 minor revision #7308
Comments
@xiang90 asked some questions in another thread.
If i understand the question correctly, online is best. It's ideal if the changes made to the data on disk don't render that data unreadable by the previous version.
What's an example of a feature where this question would come up? I think the answer will be to think about the safety and semantics users will expect around rollback of the specific feature, but maybe we can come up with a principle.
What happens today if only a part of the cluster is upgraded? One idea is that nothing happens unless a quorum can be found all sharing the same version. |
We already ensure this today. The on-disk entry format is protobuf. Reading an entry with previous pb will result in some unknown values, but will not panic anything.
What does this mean exactly? Say in version M+1, we introduce a new filed called "Dog". Once we rollback to version M, the "Dog" field will magically disappear. This is probably OK for non-clustered systems. But for etcd, this means you can get "Dog" field from a node running version M+1, but not a node rollbacked to M. What is more magic is that, if you upgrade the node again "Dog" will appear again. Client will see inconsistent state based on which node they talk to.
I am not super worry about this. Rewriting the WAL or even DB is not hard. |
this is very different. the cluster cannot use ANY new feature until ALL members are upgraded. Here is an example [3.0, 3.0, 3.0] -> only write 3.0 entry and only 3.0 feature If you only downgrade one member, it breaks the rule and client will see inconsistent state "unavoidably". T1 [3.1, 3.1, 3.1] -> 3.1 is enabled! However, T2 becomes a magic timestamp... Clients will get confused... Why a filed is cleared?! I would love to hear how similar systems work for downgrade path. Any open source clustered system or google internal examples would be super helpful. |
What are some concrete examples of user-visible fields that etcd has introduced or plans to introduce? |
For example, we introduced PrevKV field to return the previous value of a key when modifying a key, which can save one round trip time. We introduce some fields in the range request for querying revision ranges. There are more fields we might introduce in the future. Also there might be new APIs, like native locking API. |
@mml Any update on this issue? |
I do not think this can happen in 3.2 timeframe. But I REALLY want to sort this out to make Kubernetes users happy. Please ping us when you guys have time. I am looping some other people in since I feel they are interested in this as well. |
move this to 3.4 |
Updates: @wenjiaswe is working on this. We are reviewing the design doc. |
Where is the doc? |
@philips Any suggestion or comments are welcome and appreciated! |
assign @YoyinZyc |
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
@wenjiaswe i could not open the downgrade documents, did you have a new link? |
@zaisongz I just checked the design doc linked here: https://docs.google.com/document/d/1mSihXRJz8ROhXf4r5WrBGc8aka-b8HKjo2VDllOc6ac/edit#heading=h.e4jdx621yd8s. It is shared with |
@wenjiaswe just realized it is casued by the my proxy setting, everthing is good now. Thanks a lot for your quick response. |
Motivation
This is a feature request to make rolling out upgrades safer, specifically for kubernetes cluster admins, but this could easily apply to others. It's often the case that a user may upgrade k8s from N-1 to N. Let's say that we'd like N to also include a change of the bundled etcd from M-1 to M.
k8s vN may include bugs that aren't acceptable. The easiest resolution is usually to roll back to N-1, and to avoid having to test N-1 against two versions of etcd (M-1 and M), we'd prefer that etcd be rolled back to M-1. Another reason we may wish to go back to M-1 is that the source of the bug is etcd itself.
Request
Ideally, the storage format changes between adjacent revisions are such that whatever M is writing to disk is by-design readable by M-1. It may contain new features, but they will be harmlessly ignored in the event of a rollback. One example of an encoding that works like this is proto2, which ignores unknown fields. (This isn't to advocate proto2, just to give an example.)
That said, even if etcd stabilizes on an encoding with these properties, it might want to change that encoding scheme in the future. In that case it makes sense to treat both upgrade and downgrade equally, authoring and testing tools that go in both directions, and testing round-tripping in both directions.
@xiang90 @hongchaodeng @heyitsanthony @wojtek-t
The text was updated successfully, but these errors were encountered: