Skip to content

Conversation

@gwbrown
Copy link
Contributor

@gwbrown gwbrown commented Dec 14, 2018

Adds a check for missing discovery configuration, which is now
required.

Relates to #36024 and #36215

Adds a check for missing discovery configuration, which is now
required.
@gwbrown gwbrown requested a review from DaveCTurner December 14, 2018 23:45
@gwbrown
Copy link
Contributor Author

gwbrown commented Dec 14, 2018

This might falsely give a warning if you run the check against a node that does not have discovery.type: single-node explicitly set, but I'm also not sure we really care about running this tool in a non-production environment.

@elasticmachine
Copy link
Collaborator

Pinging @elastic/es-core-features

Copy link
Contributor

@DaveCTurner DaveCTurner left a 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")))) {
Copy link
Contributor

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:

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:

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)
Copy link
Contributor

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
Copy link
Contributor

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")
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

And here :)

@gwbrown
Copy link
Contributor Author

gwbrown commented Dec 17, 2018

@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!

@gwbrown
Copy link
Contributor Author

gwbrown commented Dec 17, 2018

@elasticmachine run gradle build tests 2

Copy link
Contributor

@DaveCTurner DaveCTurner left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM thanks @gwbrown

@gwbrown gwbrown merged commit 4329058 into elastic:6.x Dec 18, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants