Skip to content
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

[FEATURE] Change the "master" nomenclature #450

Closed
Tracked by #2589 ...
tlfeng opened this issue Mar 15, 2022 · 3 comments · Fixed by #513
Closed
Tracked by #2589 ...

[FEATURE] Change the "master" nomenclature #450

tlfeng opened this issue Mar 15, 2022 · 3 comments · Fixed by #513
Assignees
Labels
enhancement New feature or request good first issue Good for newcomers upcoming release Don't merge until the version or feature is available v2.0.0
Milestone

Comments

@tlfeng
Copy link
Contributor

tlfeng commented Mar 15, 2022

Is your feature request related to a problem?
OpenSearch repository is going to replace the terminology "master"with "cluster manager".
issue: opensearch-project/OpenSearch#472 (comment), with the plan for its terminology replacement.

The existing OpenSearch REST APIs and settings will be deprecated in version 2.0, and eventually be removed in at least version 3.0. Please prepare for the nomenclature change in advance.

What solution would you like?
Replace the terminology "master" with "cluster manager".

  1. Inform the user about the nomenclature change in advance in the documentation.
  2. Replace all the internal usages with "master" word in the code base.

The impact to the OpenSearch user of the nomenclature change:

  • REST APIs and settings that contain "master" word will be deprecated in version 2.0. They are still able to be used, but using deprecated APIs and settings will result in a deprecation warning logged in file.
  • Alternative usages with "cluster_manager" word is preferred to be used, which are provided for every deprecated usages.

For detailed code change, please see the issue opensearch-project/OpenSearch#1549.

List of REST API and setting changes:
For all the non-inclusive REST APIs and settings list, please see the replacement plan of master terminology for OpenSearch repository: opensearch-project/OpenSearch#472 (comment)
Setting names

1 cluster.initial_master_nodes (static)
New name: cluster.initial_cluster_manager_nodes

2 cluster.no_master_block (dynamic)
New name: cluster.no_cluster_manager_block

3 cluster.service.slow_master_task_logging_threshold (dynamic)
New name: cluster.service.slow_cluster_manager_task_logging_threshold

Expected behavior (same as the deprecated OpenDistro settings of plugins):

  • If the new setting is configured, value of the old setting will be ignored.
  • If the new setting is not configured, value of the old setting will be valid.

Setting value

1 node.roles: [ master ]
New name of the master role : cluster_manager

  • A new node role will be added, aims to replace the existing master role. New node created by OpenSearch 2.0 will have cluster_manager role and without master role by default, but they have got the same functionality.
  • New node will have "cluster_manager", "data", and "ingest" roles by default. Which means the default value of setting "node.roles" will be ["cluster_manager","data","ingest"], instead of ["master","data","ingest"]
  • master role and cluster_manager role can not be assigned together to a node.
  • See the link for detailed changes in responses of REST APIs Add a new node role 'cluster_manager' as the alternative for 'master' role and deprecate 'master' role OpenSearch#2424.

REST API endpoint
1 GET _cat/master
New name: GET _cat/cluster_manager

  • Using the old path _cat/master and new path _cat/cluster_manager will get the same response.

REST API path parameter
1 "node filters" used in some cluster-level APIs. The APIs are usually in the format: GET /_nodes/<node_id>, where <node_id> can be set as _master or master:true or master:false to filter the master nodes.

  • The filter names are based on the node roles, since a new node role is added, cluster_manager can also be used to filter nodes to be shown in the API response. Besides, master and cluster_manager have got the same filtering effect, and they will filter the node with either role.

REST API request parameter name
1 master_timeout=
New name: cluster_manager_timeout=

  • A new optional parameter cluster_manager_timeout will be added, and it has the same effect with the existing master_timeout. An exception will be thrown if values are assigned to the both parameters.
  • The parameter is widely used in REST APIs

REST API request parameter value
1 metric=master_node
New name: metric=cluster_manager_node

  • Use either master_node or cluster_manager_node can get the same metrics.
  • So far, the metric parameter is used in GET /_cluster/state/<metrics>/<target> and POST /_cluster/reroute APIs

REST API response field
1 discovered_master in the response of GET _cluster/health
New name: discovered_cluster_manager

  • a new field will be added to GET _cluster/health API: discovered_cluster_manager, though the "old" field discovered_master has not been added to the document yet.

2 discovered_master in the response of GET _cat/health

  • the header discovered_master of the table in the response of GET _cat/health API will be replaced by discovered_cluster_manager (breaking change)
  • If user wants to get output with the old column header name master, please use h parameter to filter the column to be shown explicitly, such as GET _cat/health?v&h=master

3 master in the response of GET _cat/nodes
master -> cluster_manager

  • the header master of the table in the response of GET _cat/nodes API will be replaced by cluster_manager (breaking change)
  • If user wants to get output with the old column header name master, please use h parameter to filter the column to be shown explicitly, such as GET _cat/nodes?v&h=version,master

What alternatives have you considered?
none.

Do you have any additional context?
none.

@tlfeng tlfeng added enhancement New feature or request untriaged upcoming release Don't merge until the version or feature is available v2.0.0 labels Mar 15, 2022
@Naarcha-AWS
Copy link
Collaborator

Thanks @tlfeng! We'll get this in before the upcoming preview.

@Naarcha-AWS Naarcha-AWS self-assigned this Mar 21, 2022
@keithhc2 keithhc2 added the good first issue Good for newcomers label Apr 4, 2022
@dblock dblock changed the title [FEATURE] Change the "master" nomenclature [FEATURE] Deprecate the "master" nomenclature Apr 18, 2022
alicejw1 added a commit to alicejw1/documentation-website that referenced this issue Apr 18, 2022
alicejw1 added a commit to alicejw1/documentation-website that referenced this issue Apr 18, 2022
Signed-off-by: alicejw <alicejw@amazon.com>
@alicejw1 alicejw1 linked a pull request Apr 18, 2022 that will close this issue
1 task
@lizsnyder lizsnyder assigned alicejw1 and unassigned Naarcha-AWS Apr 19, 2022
@tlfeng tlfeng changed the title [FEATURE] Deprecate the "master" nomenclature [FEATURE] Change the "master" nomenclature Apr 22, 2022
@cwillum
Copy link
Contributor

cwillum commented Sep 8, 2022

Reopening to change the cluster.initial_master_nodes setting name to cluster.initial_cluster_manager_nodes in the sample docker compose file on the Docker image page.

@cwillum
Copy link
Contributor

cwillum commented Sep 9, 2022

Boxing this back up post merge of #1151.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request good first issue Good for newcomers upcoming release Don't merge until the version or feature is available v2.0.0
Projects
None yet
Development

Successfully merging a pull request may close this issue.

5 participants