[
https://issues.apache.org/jira/browse/MESOS-9448?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16792789#comment-16792789
]
Vinod Kone commented on MESOS-9448:
-----------------------------------
[~greggomann] Can we close this as a dup of MESOS-9318?
> Semantics of RECONCILE_OPERATIONS framework API call are incorrect
> ------------------------------------------------------------------
>
> Key: MESOS-9448
> URL: https://issues.apache.org/jira/browse/MESOS-9448
> Project: Mesos
> Issue Type: Bug
> Components: framework, HTTP API, master
> Reporter: Benjamin Bannier
> Priority: Major
>
> The typical pattern in the framework HTTP API is that frameworks send calls
> to which the master responds with {{Accepted}} responses and which trigger
> events. The only designed exception to this are {{SUBSCRIBE}} calls to which
> the master responds with an {{Ok}} response containing the assigned framework
> ID. This is even codified in {{src/scheduler.cpp:646ff}},
> {code}
> if (response->code == process::http::Status::OK) {
> // Only SUBSCRIBE call should get a "200 OK" response.
> CHECK_EQ(Call::SUBSCRIBE, call.type());
> {code}
> Currently, the handling of {{RECONCILE_OPERATIONS}} calls does not follow
> this pattern. Instead of sending events, the master immediately responds with
> a {{Ok}} and a list of operations. This e.g., leads to assertion failures in
> above hard check whenever one uses the {{Scheduler::send}} instead of
> {{Scheduler::call}}. One can reproduce this by modifying the existing tests
> in {{src/operation_reconciliation_tests.cpp}},
> {code}
> mesos.send({createCallReconcileOperations(frameworkId, {operation})}); // ADD
> THIS.
> const Future<scheduler::APIResult> result =
> mesos.call({createCallReconcileOperations(frameworkId, {operation})});
> {code}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
