-
Notifications
You must be signed in to change notification settings - Fork 24.9k
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
Deprecate minimum_master_nodes #37868
Deprecate minimum_master_nodes #37868
Conversation
Today the `discovery.zen.minimum_master_nodes` setting is ignored in 7.0 but must still be permitted to live as a cluster-level setting for cases where 6.x nodes leave and rejoin the cluster. However there is no good reason for it to exist as a node-level setting on 7.0 nodes. This change prevents a 7.0 node from starting up with the `discovery.zen.minimum_master_nodes` setting set.
Pinging @elastic/es-distributed |
We are still debating whether we should actually forbid this setting like this. However even if we decide not to do so, this PR removes many places in which we depend on this setting. |
@elasticmachine please run elasticsearch-ci/1 |
buildSrc/src/main/groovy/org/elasticsearch/gradle/test/ClusterFormationTasks.groovy
Outdated
Show resolved
Hide resolved
buildSrc/src/main/groovy/org/elasticsearch/gradle/test/ClusterFormationTasks.groovy
Outdated
Show resolved
Hide resolved
@@ -194,7 +195,8 @@ public Settings onNodeStopped(String nodeName) { | |||
} | |||
ClusterHealthResponse clusterHealthResponse = clusterHealthRequestBuilder.get(); | |||
assertFalse(nodeName, clusterHealthResponse.isTimedOut()); | |||
return Coordinator.addZen1Attribute(false, Settings.builder().put(ZEN2_SETTINGS)).build(); | |||
return Coordinator.addZen1Attribute(false, Settings.builder().put(ZEN2_SETTINGS) | |||
.put(ElectMasterService.DISCOVERY_ZEN_MINIMUM_MASTER_NODES_SETTING.getKey(), Integer.MAX_VALUE)).build(); |
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.
add a comment why this is set to MAX_VALUE? Typically you would expect this to be unconfigured. Or we could randomize between unconfigured, configured to num_nodes / 2 + 1 and MAX_VALUE (in case user forgot to remove setting in upgrade)
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.
I replaced it with a more specific name in 9137ad2. The point is that there's no facility to remove a setting via this API, so we set it to an explicitly silly value and then assert that this is what we wanted when removing it here:
elasticsearch/test/framework/src/main/java/org/elasticsearch/test/InternalTestCluster.java
Lines 993 to 1001 in 9137ad2
// simulating an upgrade from Zen1 to Zen2, but there's no way to remove a setting when restarting a node, so | |
// you have to set it to REMOVED_MINIMUM_MASTER_NODES (== Integer.MAX_VALUE) to indicate its removal: | |
assertTrue(USE_ZEN2.exists(finalSettings)); | |
assertTrue(USE_ZEN2.get(finalSettings)); | |
assertThat(DISCOVERY_ZEN_MINIMUM_MASTER_NODES_SETTING.get(finalSettings), equalTo(REMOVED_MINIMUM_MASTER_NODES)); | |
final Builder builder = Settings.builder().put(finalSettings); | |
builder.remove(DISCOVERY_ZEN_MINIMUM_MASTER_NODES_SETTING.getKey()); | |
finalSettings = builder.build(); |
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.
How about doing .putNull(ElectMasterService.DISCOVERY_ZEN_MINIMUM_MASTER_NODES_SETTING.getKey())
here and then
assertThat(DISCOVERY_ZEN_MINIMUM_MASTER_NODES_SETTING.get(finalSettings),
equalTo(DISCOVERY_ZEN_MINIMUM_MASTER_NODES_SETTING.getDefault(finalSettings)));
in InternalTestCluster
?
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 it to null
is a legitimate thing that a test might do, and I want to assert that this is not what has happened here.
@elasticmachine run elasticsearch-ci/1 run elasticsearch-ci/default-distro |
@elasticmachine run elasticsearch-ci/1 run elasticsearch-ci/docs-check |
@elasticmachine run elasticsearch-ci/2 |
* elastic/master: ILM setPriority corrections for a 0 value (elastic#38001) Temporarily disable BWC for retention lease stats (elastic#38049) Skip Shrink when numberOfShards not changed (elastic#37953) Add dispatching to `HandledTransportAction` (elastic#38050) Update httpclient for JDK 11 TLS engine (elastic#37994) Reduce flaxiness of ccr recovery timeouts test (elastic#38035) Fix ILM status to allow unknown fields (elastic#38043) Fix ILM Lifecycle Policy to allow unknown fields (elastic#38041) Update verify repository to allow unknown fields (elastic#37619) [ML] Datafeed deprecation checks (elastic#38026) Deprecate minimum_master_nodes (elastic#37868) Remove types from watcher docs (elastic#38002) Add test coverage for Painless general casting of boolean and Boolean (elastic#37780) Fixed test bug, lastFollowTime is null if there are no follower indices. Add ECS schema for user-agent ingest processor (elastic#37727) (elastic#37984) Extract TransportRequestDeduplication from ShardStateAction (elastic#37870)
…r-primary-term * elastic/master: Mute failing date index name processor test Reenable BWC testing after retention lease stats (elastic#38062) Move watcher to use seq# and primary term for concurrency control (elastic#37977) ILM setPriority corrections for a 0 value (elastic#38001) Temporarily disable BWC for retention lease stats (elastic#38049) Skip Shrink when numberOfShards not changed (elastic#37953) Add dispatching to `HandledTransportAction` (elastic#38050) Update httpclient for JDK 11 TLS engine (elastic#37994) Reduce flaxiness of ccr recovery timeouts test (elastic#38035) Fix ILM status to allow unknown fields (elastic#38043) Fix ILM Lifecycle Policy to allow unknown fields (elastic#38041) Update verify repository to allow unknown fields (elastic#37619) [ML] Datafeed deprecation checks (elastic#38026) Deprecate minimum_master_nodes (elastic#37868)
Zen discovery and its associated settings were deprecated in 7.0. This commit adds an entry to the release notes calling this out. Relates elastic#38289 elastic#38333 elastic#38350 elastic#37868
Today we pass
discovery.zen.minimum_master_nodes
to nodes started up intests, but for 7.x nodes this setting is not required as it has no effect.
This commit removes this setting so that nodes are started with more realistic
configurations, and deprecates it.