You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Chun-Hung Hsiao (JIRA)" <ji...@apache.org> on 2019/05/10 22:14:00 UTC

[jira] [Assigned] (MESOS-9779) `UPDATE_RESOURCE_PROVIDER_CONFIG` agent call returns 404 ambiguously.

     [ https://issues.apache.org/jira/browse/MESOS-9779?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Chun-Hung Hsiao reassigned MESOS-9779:
--------------------------------------

    Assignee: Chun-Hung Hsiao

> `UPDATE_RESOURCE_PROVIDER_CONFIG` agent call returns 404 ambiguously.
> ---------------------------------------------------------------------
>
>                 Key: MESOS-9779
>                 URL: https://issues.apache.org/jira/browse/MESOS-9779
>             Project: Mesos
>          Issue Type: Bug
>          Components: agent, HTTP API, resource provider
>            Reporter: Chun-Hung Hsiao
>            Assignee: Chun-Hung Hsiao
>            Priority: Major
>
> The {{UPDATE_RESOURCE_PROVIDER_CONFIG}} API call returns 404 if the specified resource provider does not exist. However, libprocess also returns 404 when the `/api/v1` route is not set up. As a result, a client will get confused when receiving 404 and wouldn't know the actual state of the resource provider config. We should not overload 404 with different errors.
> The other codes for client errors returned by this call are:
> * 400 if the request is not well-formed.
> * 403 if the call is not authorized.
> To avoid ambiguity, we could keep 404 to represent that the requested URI does not exist, and use 409 to indicate that based on the current the current agent state, the update request cannot be done because the specified resource provider config does not exist, similar to what a PATCH command would return if certain elements do not exist in the requsted resource (https://www.ietf.org/rfc/rfc5789.txt):
> {noformat}
>    Conflicting state:  Can be specified with a 409 (Conflict) status
>       code when the request cannot be applied given the state of the
>       resource.  For example, if the client attempted to apply a
>       structural modification and the structures assumed to exist did
>       not exist (with XML, a patch might specify changing element 'foo'
>       to element 'bar' but element 'foo' might not exist).
> {noformat}
> Adapting 409 also makes {{UPDATE_RESOURCE_PROVIDER_CONFIG}} symmetric to {{ADD_RESOURCE_PROVIDER_CONFIG}}.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)