Skip to content

Allocation explain should accept query-string parameters #127028

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

Open
DaveCTurner opened this issue Apr 17, 2025 · 1 comment
Open

Allocation explain should accept query-string parameters #127028

DaveCTurner opened this issue Apr 17, 2025 · 1 comment
Labels
:Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) >enhancement Supportability Improve our (devs, SREs, support eng, users) ability to troubleshoot/self-service product better. Team:Distributed Coordination Meta label for Distributed Coordination team

Comments

@DaveCTurner
Copy link
Contributor

Today allocation explain takes its parameters in the request body:

GET _cluster/allocation/explain
{
  "index": "my-index-000001",
  "shard": 0,
  "primary": false,
  "current_node": "my-node"
}

Leaving aside the question of the validity of GET-with-body (you can use POST here) it's also just kinda awkward to pass in a flat map of 4 somewhat-optional parameters in the body. We could just as well make the API accept the same parameters in the query-part of the URI1:

GET _cluster/allocation/explain?index=my-index-000001&shard=0&primary=false&current_node=my-node

Note that we probably shouldn't accept a mix of these two styles: if there are any parameters, they must all be in the body or all in the query string. We might even want to deprecate the use of the body for these arguments and remove it in the next major?

Footnotes

  1. Technically ok you can already do this using the source and source_content_type params:

    GET _cluster/allocation/explain?source_content_type=application/json&source=%7B%22index%22%3A%22my-index-000001%22%2C%22shard%22%3A0%2C%22primary%22%3Afalse%2C%22current_node%22%3A%22my-node%22%7D
    

    But eh that's not all that nice is it?

@DaveCTurner DaveCTurner added :Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) >enhancement Supportability Improve our (devs, SREs, support eng, users) ability to troubleshoot/self-service product better. labels Apr 17, 2025
@elasticsearchmachine elasticsearchmachine added the Team:Distributed Coordination Meta label for Distributed Coordination team label Apr 17, 2025
@elasticsearchmachine
Copy link
Collaborator

Pinging @elastic/es-distributed-coordination (Team:Distributed Coordination)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
:Distributed Coordination/Allocation All issues relating to the decision making around placing a shard (both master logic & on the nodes) >enhancement Supportability Improve our (devs, SREs, support eng, users) ability to troubleshoot/self-service product better. Team:Distributed Coordination Meta label for Distributed Coordination team
Projects
None yet
Development

No branches or pull requests

2 participants