Details
Description
Some of the API endpoints, for example /master/tasks.json, will return bogus information if you query a non-leading master:
[steven@Anesthetize:~]% curl http://master1.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n 10 { "tasks": [] } [steven@Anesthetize:~]% curl http://master2.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n 10 { "tasks": [] } [steven@Anesthetize:~]% curl http://master3.mesos-vpcqa.otenv.com:5050/master/tasks.json | jq . | head -n 10 { "tasks": [ { "executor_id": "", "framework_id": "20140724-231003-419644938-5050-1707-0000", "id": "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db", "name": "pp.guestcenterwebhealthmonitor.606cd6ee-4b50-11e4-825b-5212e05f35db", "resources": { "cpus": 0.25, "disk": 0,
This is very hard for end-users to work around. For example if I query "which master is leading" followed by "leader: which tasks are running" it is possible that the leader fails over in between, leaving me with an incorrect answer and no way to know that this happened.
In my opinion the API should return the correct response (by asking the current leader?) or an error (500 Not the leader?) but it's unacceptable to return a successful wrong answer.
Attachments
Issue Links
- blocks
-
MESOS-2977 Add test case for redirect to the leader master when current master is not a leader.
- In Progress
- is related to
-
MESOS-4680 HTTP requests to non leading mesos-master redirect to top level page
- Resolved
-
MESOS-3841 Master HTTP API support to get the leader
- Resolved
- relates to
-
MESOS-3832 Scheduler HTTP API does not redirect to leading master
- Resolved
-
MESOS-3841 Master HTTP API support to get the leader
- Resolved