-
Notifications
You must be signed in to change notification settings - Fork 25.6k
Deprecation check for discovery configuration #36666
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
Conversation
Adds a check for missing discovery configuration, which is now required.
|
This might falsely give a warning if you run the check against a node that does not have |
|
Pinging @elastic/es-core-features |
DaveCTurner
left a comment
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 think we should check this slightly differently, but otherwise looks good.
|
|
||
| static DeprecationIssue discoveryConfigurationCheck(List<NodeInfo> nodeInfos, List<NodeStats> nodeStats) { | ||
| if (nodeInfos.size() == 1 | ||
| && nodeInfos.stream().anyMatch(nodeInfo -> "single-node".equals(nodeInfo.getSettings().get("discovery.type")))) { |
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.
Technically this check only applies if discovery.type is zen2:
elasticsearch/server/src/main/java/org/elasticsearch/bootstrap/BootstrapChecks.java
Lines 728 to 730 in cd1bec3
| if (DiscoveryModule.ZEN2_DISCOVERY_TYPE.equals(DiscoveryModule.DISCOVERY_TYPE_SETTING.get(context.settings())) == false) { | |
| return BootstrapCheckResult.success(); | |
| } |
Of course zen2 isn't a thing in 6.x so we can't check for that; I think we should check for usage of the default discovery type. We have already changed the default to zen2 in master and we hope to deprecate zen as a valid discovery type, which will I guess need another deprecation check.
FYI the comparison with single-node discovery applies to all bootstrap checks:
elasticsearch/server/src/main/java/org/elasticsearch/bootstrap/BootstrapChecks.java
Line 187 in cd1bec3
| return bound && !"single-node".equals(discoveryType); |
In practice I think we expect single-node and zen2 to be the only options here, rendering these two statements practically equivalent, but that's still to be confirmed and may change in future.
Also please could you use DiscoveryModule.DISCOVERY_TYPE_SETTING.getKey() instead of the literal setting key. It makes it that bit easier to find usages of a setting in the IDE, and that bit less likely that we miss this usage in some future work.
| // This only checks for `ping.unicast.hosts` and `hosts_provider` because `cluster.initial_master_nodes` does not exist in 6.x | ||
| List<String> nodesFound = nodeInfos.stream() | ||
| .filter(nodeInfo -> nodeInfo.getSettings().hasValue("discovery.zen.ping.unicast.hosts") == false) | ||
| .filter(nodeInfo -> nodeInfo.getSettings().hasValue("discovery.zen.hosts_provider") == false) |
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.
Please could you use SettingsBasedHostsProvider.DISCOVERY_ZEN_PING_UNICAST_HOSTS_SETTING.getKey() and DiscoveryModule.DISCOVERY_HOSTS_PROVIDER_SETTING.getKey() rather than the literal setting keys?
| Settings settings = Settings.builder() | ||
| .put("cluster.name", "elasticsearch") | ||
| .put("node.name", "node_check") | ||
| .put("discovery.type", "single-node") // Needed due to NodeDeprecationChecks#discoveryConfigurationCheck |
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.
Same request for setting keys rather than literals here please.
| null, null, null, null)); | ||
| Settings baseSettings = Settings.builder() | ||
| .put("cluster.name", "elasticsearch") | ||
| .put("node.name", "node_check") |
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.
And here :)
|
@DaveCTurner Thanks for the review! I've cleaned up the strings into setting references, and I think the check now matches what's actually required - it only checks nodes that do not have a discovery type explicitly set as otherwise Zen2 will not be used after upgrade. Please correct me if I misunderstood, though! |
|
@elasticmachine run gradle build tests 2 |
DaveCTurner
left a comment
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.
LGTM thanks @gwbrown
Adds a check for missing discovery configuration, which is now
required.
Relates to #36024 and #36215