Skip to content

Deprecation check for discovery configuration#36666

Merged
AthenaEryma merged 2 commits intoelastic:6.xfrom
AthenaEryma:depcheck/discovery-config
Dec 18, 2018
Merged

Deprecation check for discovery configuration#36666
AthenaEryma merged 2 commits intoelastic:6.xfrom
AthenaEryma:depcheck/discovery-config

Conversation

@AthenaEryma
Copy link
Copy Markdown
Contributor

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.
@AthenaEryma
Copy link
Copy Markdown
Contributor Author

AthenaEryma 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
Copy Markdown
Collaborator

Pinging @elastic/es-core-features

Copy link
Copy Markdown
Member

@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
Copy Markdown
Member

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
Copy Markdown
Member

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
Copy Markdown
Member

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
Copy Markdown
Member

Choose a reason for hiding this comment

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

And here :)

@AthenaEryma
Copy link
Copy Markdown
Contributor Author

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

@AthenaEryma
Copy link
Copy Markdown
Contributor Author

@elasticmachine run gradle build tests 2

Copy link
Copy Markdown
Member

@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

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