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

• Type: Improvement
• Status: Open
• Priority: Major
• Resolution: Unresolved
• Affects Version/s: 0.24.0
• Labels: mesosphere
• Epic Link: Scheduler API v1 improvements
• Assignee: Unassigned
• Reporter: James DeFelice
• Created: 29/Jan/16 01:15
• Updated: 07/Feb/17 18:48

Description

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 Vinod Kone, Benjamin Mahler

Issue Links

• duplicates: MESOS-2522 Add reason field for framework errors
• is related to: MESOS-5363 Content-Type for HTTP error responses should match Accept-Type in requests
• relates to: MESOS-5322 Add "reason" field to FAILURE event in HTTP scheduler API