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

Add alternative usages for the REST APIs and configurations that contain "master" terminology #1549

Closed
12 tasks done
tlfeng opened this issue Nov 15, 2021 · 2 comments
Closed
12 tasks done
Assignees
Labels
>breaking Identifies a breaking change. enhancement Enhancement or improvement to existing feature or request v2.0.0 Version 2.0.0

Comments

@tlfeng
Copy link
Collaborator

tlfeng commented Nov 15, 2021

Is your feature request related to a problem? Please describe.
Replace "master" terminology in REST APIs and configurations, where the backwards compatibility will be impacted.

A part of #472

Describe the solution you'd like

  1. Replace the old usages that having the word "master" with "cluster manager" in REST APIs and configurations, then create duplicate usages with the original name for backwards compatibility (including fallback logic to fallback to settings with the new name).
  2. Add tests to check both old and new usages of the REST APIs and configurations.
  3. Add proper deprecation notice to the old usages.

Sub-tasks:

Setting name:

Setting value:

REST API endpoint:

REST API path parameter:

REST API request parameter name:

REST API request parameter value:

REST API response field:

Describe alternatives you've considered
None.

Additional context
Location that contains the exclusionary term and will impact the compatibility when changed:
Setting names
1 Discovery and cluster formation settings
cluster.initial_master_nodes (static)
cluster.no_master_block (dynamic)
discovery.zen.no_master_block
discovery.zen.minimum_master_nodes
discovery.zen.master_election.*
Note: discovery.zen.* settings are already deprecated in Elasticsearch 7.0, but code remains to be removed. Update: they have been removed in OpenSearch 2.0 by the commit 4db97aa

2 Local gateway settings
gateway.expected_master_nodes
gateway.recover_after_master_nodes
Note: the above 2 settings are already deprecated in Elasticsearch 7.7, but code remains to be removed.

3 Miscellaneous
cluster.service.slow_master_task_logging_threshold (dynamic)
Code: https://github.com/opensearch-project/OpenSearch/blob/1.0.0/server/src/main/java/org/opensearch/cluster/service/MasterService.java#L90

Setting values
1 Node roles
node.roles: [ master ] (static)

REST API endpoints
1 cat master
GET _cat/master

REST API path parameters
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.
Nodes Info API API - GET /_nodes/<node_id>
Nodes stats API - GET /_nodes/<node_id>/stats , GET/_nodes/<node_id>/stats/<metric> , GET /_nodes/<node_id>/stats/<metric>/<index_metric>
Nodes feature usage API - GET /_nodes/<node_id>/usage , GET /_nodes/<node_id>/usage/<metric>
Nodes hot threads API - GET /_nodes/<node_id>/hot_threads
Nodes reload secure settings API - POST /_nodes/<node_id>/reload_secure_settings
Task management API - GET _tasks?nodes=<node_id>

REST API request parameter names
1 master_timeout (used in multiple APIs)

REST API request parameter values
1 metric=master_node
Cluster reroute API - POST /_cluster/reroute
Cluster state API - GET /_cluster/state/<metrics>/<target>

REST API response fields
1 discovered_master
Response of GET _cluster/health
doc: https://opensearch.org/docs/latest/opensearch/rest-api/cluster-health/#response
code: https://github.com/opensearch-project/OpenSearch/blob/1.1.0/server/src/main/java/org/opensearch/action/admin/cluster/health/ClusterHealthResponse.java#L69
Response of GET _cat/health (in the header of table)
doc: https://opensearch.org/docs/latest/opensearch/rest-api/cat/cat-health/#response
code: https://github.com/opensearch-project/OpenSearch/blob/1.2.4/server/src/main/java/org/opensearch/rest/action/cat/RestHealthAction.java#L91

2 cat nodes
Response of GET _cat/nodes

The guide for plugins can be a reference: https://github.com/opensearch-project/opensearch-plugins/blob/ece53bf9e93403272726eb6087ed98f9c821502b/UPGRADING.md#settings

@tlfeng tlfeng added enhancement Enhancement or improvement to existing feature or request untriaged labels Nov 15, 2021
@tlfeng tlfeng changed the title Replace "blacklist/whitelist" terminology in APIs and configurations Replace "master" terminology in APIs and configurations Nov 15, 2021
@tlfeng tlfeng removed the untriaged label Nov 15, 2021
@tlfeng tlfeng changed the title Replace "master" terminology in APIs and configurations Add duplicate APIs and configurations that contain "master" terminology Nov 16, 2021
@tlfeng tlfeng changed the title Add duplicate APIs and configurations that contain "master" terminology Add duplicate REST APIs and configurations that contain "master" terminology Dec 9, 2021
@tlfeng tlfeng changed the title Add duplicate REST APIs and configurations that contain "master" terminology Add duplicate usages for the REST APIs and configurations that contain "master" terminology Feb 25, 2022
@tlfeng tlfeng changed the title Add duplicate usages for the REST APIs and configurations that contain "master" terminology Add alternative usages for the REST APIs and configurations that contain "master" terminology Mar 4, 2022
@saratvemulapalli saratvemulapalli added v2.0.0 Version 2.0.0 >breaking Identifies a breaking change. labels Mar 11, 2022
@tlfeng
Copy link
Collaborator Author

tlfeng commented Mar 18, 2022

Pending tasks apart from the above PRs:

@tlfeng
Copy link
Collaborator Author

tlfeng commented Apr 21, 2022

All required changes for version 2.0 are completed.
All the REST APIs and Settings which contain "master" terminology have got inclusive alternatives.
All the non-inclusive REST APIs and Settings are deprecated in version 2.0, except REST API request parameter master_timeout. (See issue #2928 for the timeline of the deprecation for master_timeout)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
>breaking Identifies a breaking change. enhancement Enhancement or improvement to existing feature or request v2.0.0 Version 2.0.0
Projects
None yet
Development

No branches or pull requests

2 participants