[
https://issues.apache.org/jira/browse/MESOS-4548?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
James DeFelice updated MESOS-4548:
----------------------------------
Affects Version/s: 0.24.0
> Errors communicated to the scheduler should be associated with stable error
> codes.
> ----------------------------------------------------------------------------------
>
> Key: MESOS-4548
> URL: https://issues.apache.org/jira/browse/MESOS-4548
> Project: Mesos
> Issue Type: Improvement
> Affects Versions: 0.24.0
> Reporter: James DeFelice
> Labels: mesosphere
>
> For example, in mesos 0.24 there was a change to the error message generated
> by the master when a previously removed framework attempts to re-register:
> https://github.com/apache/mesos/commit/8661672d80cbe3ebd05e68a6fc4167b54ea139ef
> Some frameworks, rightly or not, attempt to compare the generated error
> string to "Completed framework attempted to re-register" which changed in
> mesos 0.24 to "Framework has been removed". These frameworks are now broken
> with respect to this aspect of their error handling, at least until they're
> changed to check for the new error string.
> Arguably frameworks shouldn't be comparing error strings since they're not
> guaranteed to remain stable across releases. However, mesos currently offers
> no alternative since there's no error **code** in the API.
> Furthermore, with the rise of the HTTP API there's room for two classes of
> errors: synchronous validation errors vs. asynchronous errors. It would be
> ideal to have meaningful 4xx error code responses for synchronous errors as
> well as error codes for asynchronous errors delivered via ERROR events. These
> error codes would become part of a stable API that mesos would treat just
> like the rest of its APIs, allowing for deprecation cycles before breaking
> changes - or at the very least a release note indicating an immediate
> breaking change.
> /cc [~vinodkone]
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
