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

Michael Park updated MESOS-7705:
--------------------------------
    Description: 
We output the "endpoint" format through the endpoints
for backward compatibility of external tooling. A framework should be
able to use the result of an endpoint and pass it back to Mesos,
since the result was produced by Mesos. This is especially applicable
to the V1 API. We also allow the "pre-reservation-refinement" format
because existing "resources files" are written in that format, and
they should still be usable without modification.

This is arguably a little too flexible however, and we should reconsider
restricting this in ways that are sensible.

  was:Due to some difficulties in reasoning about the resource validation, 
specifically around validation and conversion of the {{Resource}} objects 
before they can safely be used by functions that require resources to be 
validated and converted to "post-reservation-refinement" format, the 
restriction that a framework with a RESERVATION_REFINEMENT capability must 
speak "post-reservation-refinement" format was removed. We should probably add 
this back shortly, but meanwhile it shouldn't be an issue.


> Reconsider restricting the resource format for frameworks.
> ----------------------------------------------------------
>
>                 Key: MESOS-7705
>                 URL: https://issues.apache.org/jira/browse/MESOS-7705
>             Project: Mesos
>          Issue Type: Bug
>          Components: master
>            Reporter: Michael Park
>
> We output the "endpoint" format through the endpoints
> for backward compatibility of external tooling. A framework should be
> able to use the result of an endpoint and pass it back to Mesos,
> since the result was produced by Mesos. This is especially applicable
> to the V1 API. We also allow the "pre-reservation-refinement" format
> because existing "resources files" are written in that format, and
> they should still be usable without modification.
> This is arguably a little too flexible however, and we should reconsider
> restricting this in ways that are sensible.



--
This message was sent by Atlassian JIRA
(v6.4.14#64029)

Reply via email to