[jira] [Commented] (MESOS-4548) Errors communicated to the scheduler should be associated with stable error codes.

["Klaus Ma (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/MESOS-4548?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15122754#comment-15122754 ] 

Klaus Ma commented on MESOS-4548:
---------------------------------

That makes sense to add error code in {{FrameworkErrorMessage}}, so framework can take action accordingly; text/string comparing is not a good practice to me :). And we also need a document to clarify the meaning of each code for framework developer.

> 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)