This repository has been archived by the owner on Mar 30, 2020. It is now read-only.
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
This finishes up the bulk of the remaining work for the [version migation RFC][rfc]. There are two main changes: 1. Add `*ExposedClusterVersion` to the `cluster.Settings` struct. Internally, it wraps the `version` cluster setting, but it exposes it indirectly to synchronize version updates with the node's engines. More precisely, - `*ExposedClusterVersion` is initialized with the persisted version early in the `Node` startup sequence - the `Node` registers itself for notifications whenever the `version` changes - `*ExposedClusterVersion` only exposes a change in the underlying `version` variable to callers *after* calling the `Node` callback (which in turn persists the update to all engines). - The result is that whenever `IsActive()` or `Version()` is called, the returned version is safe to use or to migrate to without having to worry about backwards compatibility. 1. Add code that synthesizes from and writes the version to the engines. This mostly picks up #17155 with some code golf that refactors the node startup sequence appropriately, making sure that even when there are stores that need (asynchronous) bootstrapping, they'll still have the cluster version persisted at the end. TODO: - [ ] Testing. - [ ] Update the RFC. - [ ] Pave the way for future use of `UseVersion < MinVersion`, if still required. - [ ] Migration that makes sure there's always a cluster version settings able entry (@m-schneider). - [ ] Disallow version bump if settings table has no value entry. - [ ] Consider removing the reliance on gossip callback ordering. Gossip does not *guarantee* that version updates arrive in-order, and we currently persist the cluster version blindly. `*ExposedClusterVersion` would have to do its own synthesis to refuse illegal changes backwards. This may be a non-issue but needs some consideration (all of the cluster settings would be vulnerable to it). [rfc]: cockroachdb/cockroach#16977
- Loading branch information