You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Kapil Arya (JIRA)" <ji...@apache.org> on 2018/01/24 19:49:00 UTC

[jira] [Assigned] (MESOS-7258) Provide scheduler calls to subscribe to additional roles and unsubscribe from roles.

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

Kapil Arya reassigned MESOS-7258:
---------------------------------

    Assignee: Kapil Arya

> Provide scheduler calls to subscribe to additional roles and unsubscribe from roles.
> ------------------------------------------------------------------------------------
>
>                 Key: MESOS-7258
>                 URL: https://issues.apache.org/jira/browse/MESOS-7258
>             Project: Mesos
>          Issue Type: Improvement
>          Components: master, scheduler api
>            Reporter: Benjamin Mahler
>            Assignee: Kapil Arya
>            Priority: Major
>              Labels: multitenancy
>
> The current support for schedulers to subscribe to additional roles or unsubscribe from some of their roles requires that the scheduler obtain a new subscription with the master which invalidates the event stream.
> A more lightweight mechanism would be to provide calls for the scheduler to subscribe to additional roles or unsubscribe from some roles such that the existing event stream remains open and offers to the new roles arrive on the existing event stream. E.g.
> SUBSCRIBE_TO_ROLE
>  UNSUBSCRIBE_FROM_ROLE
> One open question pertains to the terminology here, whether we would want to avoid using "subscribe" in this context. An alternative would be:
> UPDATE_FRAMEWORK_INFO
> Which provides a generic mechanism for a framework to perform framework info updates without obtaining a new event stream.
> In addition, it would be easier to use if it returned 200 on success and an error response if invalid, etc. Rather than returning 202.
> *NOTE*: Not specific to this issue, but we need to figure out how to allow the framework to not leak reservations, e.g. MESOS-7651.



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