-
Notifications
You must be signed in to change notification settings - Fork 25.2k
AddVotingConfigExclusionsAction not honoring max_voting_config_exclusions value from yml #53455
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
Comments
Pinging @elastic/es-distributed (:Distributed/Cluster Coordination) |
Thanks for the analysis @shwetathareja, I agree. However, you should not need more than 10 tombstones as a matter of course. Clusters should have a lot less than 10 master-eligible nodes, and you should clear the tombstones as soon as they're no longer needed. |
Today we only read `cluster.max_voting_config_exclusions` from the dynamic settings in the cluster metadata, ignoring any value set in `elasticsearch.yml`. This commit addresses this. Closes elastic#53455
@DaveCTurner: Yes agreed, we should clear the tombstone entries. Also, I have observed similar issue for cluster.blocks.read_only setting which is NodeScope but doesn't honor static value from yml. |
Today we only read `cluster.max_voting_config_exclusions` from the dynamic settings in the cluster metadata, ignoring any value set in `elasticsearch.yml`. This commit addresses this. Closes #53455
Today we only read `cluster.max_voting_config_exclusions` from the dynamic settings in the cluster metadata, ignoring any value set in `elasticsearch.yml`. This commit addresses this. Closes #53455
Elasticsearch version (
bin/elasticsearch --version
): 7.1, 7.6Description of the problem including expected versus actual behavior:
max_voting_config_exclusions setting is NodeScope but yml value is not honored in the TransportAddVotingConfigExclusionsAction and uses default value as 10 (in case persistent/ transient setting is not set)
The reason for that TransportAddVotingConfigExclusionsAction is getting the settings object from cluster state metadata which is constructed using only persistant & transient setting and doesn't have the settings object which is created in Node.java using the yml file.
from MetaData class constructor
this.settings = Settings.builder().put(persistentSettings).put(transientSettings).build();
Fix:
TransportAddVotingConfigExclusionsAction should have access to settings object constructed from yml and then applying persistent/ transient settings.
Steps to reproduce:
The text was updated successfully, but these errors were encountered: