settings: delete StateMachineSetting, introduce VersionSetting#55994
settings: delete StateMachineSetting, introduce VersionSetting#55994craig[bot] merged 2 commits intocockroachdb:masterfrom
Conversation
76605e1 to
4bac320
Compare
knz
left a comment
There was a problem hiding this comment.
Reviewed 1 of 1 files at r1, 14 of 14 files at r2.
Reviewable status:complete! 0 of 0 LGTMs obtained (waiting on @irfansharif and @tbg)
pkg/settings/setting.go, line 220 at r2 (raw file):
// called on the goroutine which handles all settings updates. SetOnChange(sv *Values, fn func()) ErrorHint() (bool, string)
I applaud you for stepping out of your way to add these comments! Maybe ErrorHint() can get one too?
pkg/settings/settings_test.go, line 29 at r2 (raw file):
type dummyVersion struct { // Each dummyVersion has a msg1 prefix, and a growsbyone component that
Pull this comment above the struct.
tbg
left a comment
There was a problem hiding this comment.
Looks good. I also think you're on to some additional (deeper?) cleanup regarding the initialization of the setting and perhaps even the Opaque thing.
Reviewed 1 of 1 files at r1, 14 of 14 files at r2.
Reviewable status:complete! 0 of 0 LGTMs obtained (waiting on @irfansharif)
pkg/settings/version.go, line 71 at r2 (raw file):
// cyclical dependency structure. type ClusterVersionImpl interface { ClusterVersionImpl()
Do we still need Values.opaque after this change?
pkg/settings/version.go, line 79 at r2 (raw file):
// MakeVersionSetting instantiates a version setting instance. See // VersionSetting for additional commentary.jhk
jhk
pkg/settings/version.go, line 186 at r2 (raw file):
// time. // // TODO(irfansharif): Is this true? Shouldn't the default here just the the
Yes, I think there is something there. We call .setToDefault in two places:
- in
SettingsValues.Init, at which point the cluster version is generally initialized - in the settings updater, which is even later
I think we could pass the default through the (*Settings).Values and use setToDefault here then. I.e. this code
cockroach/pkg/settings/cluster/cluster_settings.go
Lines 150 to 153 in 7bed111
would do something like
ClusterVersionSetting.Override(&st.SV, "19.2-1")
sv.Init(handle)Also look at this code, it's basically setting the version like any other setting, really looks like everything here should go away and the setting should look like any other:
cockroach/pkg/settings/cluster/settings.go
Lines 135 to 150 in 6ae15a7
4bac320 to
e7d1e4a
Compare
irfansharif
left a comment
There was a problem hiding this comment.
Thanks for reviewing! Like Tobi mentioned, this paves the way for more deep cleansing here. I have them sitting aside as separate commits that already touch the areas identified below (which is where to TODOs came from). I'll send those out in future PRs. We'll also be able to remove this whole SetBeforeChange callback business and shave the interfaces down even further.
bors r+
Reviewable status:
complete! 0 of 0 LGTMs obtained (waiting on @knz and @tbg)
pkg/settings/setting.go, line 220 at r2 (raw file):
Previously, knz (kena) wrote…
I applaud you for stepping out of your way to add these comments! Maybe
ErrorHint()can get one too?
Done.
pkg/settings/settings_test.go, line 29 at r2 (raw file):
Previously, knz (kena) wrote…
Pull this comment above the struct.
Done.
pkg/settings/version.go, line 71 at r2 (raw file):
Previously, tbg (Tobias Grieger) wrote…
Do we still need
Values.opaqueafter this change?
Nope, see top-level comment.
pkg/settings/version.go, line 79 at r2 (raw file):
Previously, tbg (Tobias Grieger) wrote…
jhk
imap jhk <Esc>lDone
pkg/settings/version.go, line 186 at r2 (raw file):
Previously, tbg (Tobias Grieger) wrote…
Yes, I think there is something there. We call
.setToDefaultin two places:
- in
SettingsValues.Init, at which point the cluster version is generally initialized- in the settings updater, which is even later
I think we could pass the default through the
(*Settings).Valuesand usesetToDefaulthere then. I.e. this codecockroach/pkg/settings/cluster/cluster_settings.go
Lines 150 to 153 in 7bed111
would do something like
ClusterVersionSetting.Override(&st.SV, "19.2-1") sv.Init(handle)Also look at this code, it's basically setting the version like any other setting, really looks like everything here should go away and the setting should look like any other:
cockroach/pkg/settings/cluster/settings.go
Lines 135 to 150 in 6ae15a7
See top-level comment, slated for future PRs that changes even more things about cluster settings.
|
Build failed (retrying...): |
|
bors r- |
|
Canceled. |
Motivates the next commit. Release note: None
e7d1e4a to
cef56e6
Compare
|
bors r+ |
|
🕐 Waiting for PR status (Github check) to be set, probably by CI. Bors will automatically try to run when all required PR statuses are set. |
We introduced the custom StateMachineSetting type in cockroachdb#17216 to power the underlying machinery for version upgrades: SET CLUSTER SETTING version = <major>-<minor>; At the time we left it generalizable enough to make room for future settings with arbitrary internal transitions. For cluster versions this meant only allowing transitions from one major version to the immediate next, all the while making sure that each binary in the cluster was able to activate the targeted version (the proposed version fell within the allowable range ["binary min supported version", "binary version"]). In the three years since we haven't added any state-machine validated settings that fit the bill, and the layers of abstractions to get to validated cluster version updates are one too many for (my) comfort. This PR introduces a new VersionSetting type that is more tightly coupled with the ClusterVersion type itself. VersionSetting uses language that only appropriate for cluster versions, hopefully clarifying things as we go. We'll depend on this clarification in future PRs when we remove the use of gossip in disseminating cluster version bumps. Release note (sql/cli change): The underlying type for the version cluster setting has been changed. Previously it was of an internal type representing "state machine", but now it's simply "version". This has no operational implications, but it does reflect differently in a few spots: - The `Type` column in `cockroach gen settings-list` will now show "version" instead of "custom validation" - The `setting_type` column for `version` in `SHOW CLUSTER SETTINGS` will now show a "v" instead of an "m" - The `valueType` column for `version` in `system.settings` will now show a "v" instead of an "m"
cef56e6 to
3edd70b
Compare
|
bors r+ |
|
Build succeeded: |
We introduced a regression in cockroachdb#55994. In mixed-version clusters, when the 21.1 node attempts to refresh settings, it expects to find a type "v" for the version setting, but finds "m" already present in 20.2. We revert the bits of cockroachdb#55994 that introduced this regression. Release note (sql, cli change): In an earlier commit (3edd70b, not part of any release, yet) we introduced a regression by representing the shortened form of the cluster version setting's type as "v", from an earlier "m". It's now back to what it was. Specifically: - The `setting_type` column for `version` in `SHOW CLUSTER SETTINGS` will now show an "m" instead of a "v" - The `valueType` column for `version` in `system.settings` will now show an "m" instead of a "v"
We introduced a regression in cockroachdb#55994. In mixed-version clusters, when the 21.1 node attempts to refresh settings, it expects to find a type "v" for the version setting, but finds "m" already present in 20.2. We revert the bits of cockroachdb#55994 that introduced this regression. Release note (sql, cli change): In an earlier commit (3edd70b, not part of any release, yet) we introduced a regression by representing the shortened form of the cluster version setting's type as "v", from an earlier "m". It's now back to what it was. Specifically: - The `setting_type` column for `version` in `SHOW CLUSTER SETTINGS` will now show an "m" instead of a "v" - The `valueType` column for `version` in `system.settings` will now show an "m" instead of a "v"
56546: settings: patch backwards incompatible short type identifier change r=irfansharif a=irfansharif We introduced a regression in #55994. In mixed-version clusters, when the 21.1 node attempts to refresh settings, it expects to find a type "v" for the version setting, but finds "m" already present in 20.2. We revert the bits of #55994 that introduced this regression. Release note (sql, cli change): In an earlier commit (3edd70b, not part of any release, yet) we introduced a regression by representing the shortened form of the cluster version setting's type as "v", from an earlier "m". It's now back to what it was. Specifically: - The `setting_type` column for `version` in `SHOW CLUSTER SETTINGS` will now show an "m" instead of a "v" - The `valueType` column for `version` in `system.settings` will now show an "m" instead of a "v" --- First commit is from #56480. Co-authored-by: irfan sharif <irfanmahmoudsharif@gmail.com>
We introduced the custom StateMachineSetting type in #17216 to power the
underlying machinery for version upgrades:
At the time we left it generalizable enough to make room for future
settings with arbitrary internal transitions. For cluster versions this
meant only allowing transitions from one major version to the immediate
next, all the while making sure that each binary in the cluster was able
to activate the targeted version (the proposed version fell within the
allowable range ["binary min supported version", "binary version"]).
In the three years since we haven't added any state-machine validated
settings that fit the bill, and the layers of abstractions to get to
validated cluster version updates are one too many for (my) comfort.
This PR introduces a new VersionSetting type that is more tightly
coupled with the ClusterVersion type itself.
VersionSetting uses language that only appropriate for cluster versions,
hopefully clarifying things as we go. We'll depend on this clarification
in future PRs when we remove the use of gossip in disseminating cluster
version bumps.
Release note (sql/cli change): The underlying type for the version
cluster setting has been changed. Previously it was of an internal type
representing "state machine", but now it's simply "version". This has no
operational implications, but it does reflect differently in a few
spots:
Typecolumn incockroach gen settings-listwill now show"version" instead of "custom validation"
setting_typecolumn forversioninSHOW CLUSTER SETTINGSwill now show a "v" instead of an "m"
valueTypecolumn forversioninsystem.settingswill nowshow a "v" instead of an "m"