[
https://issues.apache.org/jira/browse/MESOS-1763?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15654952#comment-15654952
]
Benjamin Mahler edited comment on MESOS-1763 at 11/10/16 7:49 PM:
------------------------------------------------------------------
You can implement a multi-tenant scheduler by maintaining a scheduler per role
as you said, however there are a few issues with this approach. The overall
idea is that this introduces conceptual inaccuracy in that Mesos has no
understanding that there is a single multi-tenant scheduler.
On the mesos side, the lack of awareness of the "meta"\-scheduler has a number
of implications. Operators viewing frameworks will see a large number of
frameworks and have no first class means to see which ones belong to which
"meta"\-schedulers. In a similar vein, if they want to perform operations like
shutting down a "meta"\-scheduler, the primitives in mesos will not be able to
directly guarantee this since we only see the "sub\-"schedulers. Etc.
On the scheduler side, the implementations have tie together the notion of
multiple frameworks into a single framework. As far as we can tell, this leads
to a more complex implementation, e,g. the scheduler has to deal with
synchronization across the event streams. Another thing to consider is that
when a single-tenant scheduler wants to become multi-tenant, the jump from
single to multiple roles in this approach has a more significant impact on the
scheduler implementation.
The thinking is that as far as resource allocation is concerned we want the two
approaches (1 framework per role vs N roles per framework) to be equivalent,
but we want to more directly capture the concepts (a single multi-tenant
scheduler is the goal).
was (Author: bmahler):
You can implement a multi-tenant scheduler by maintaining a scheduler per role
as you said, however there are a few issues with this approach. The overall
idea is that this introduces conceptual inaccuracy in that Mesos has no
understanding that there is a single multi-tenant scheduler.
On the mesos side, the lack of awareness of the "meta"-scheduler has a number
of implications. Operators viewing frameworks will see a large number of
frameworks and have no first class means to see which ones belong to which
"meta"-schedulers. In a similar vein, if they want to perform operations like
shutting down a "meta"-scheduler, the primitives in mesos will not be able to
directly guarantee this since we only see the "sub-"schedulers. Etc.
On the scheduler side, the implementations have tie together the notion of
multiple frameworks into a single framework. As far as we can tell, this leads
to a more complex implementation, e,g. the scheduler has to deal with
synchronization across the event streams. Another thing to consider is that
when a single-tenant scheduler wants to become multi-tenant, the jump from
single to multiple roles in this approach has a more significant impact on the
scheduler implementation.
The thinking is that as far as resource allocation is concerned we want the two
approaches (1 framework per role vs N roles per framework) to be equivalent,
but we want to more directly capture the concepts (a single multi-tenant
scheduler is the goal).
> Add support for frameworks to receive resources for multiple roles.
> -------------------------------------------------------------------
>
> Key: MESOS-1763
> URL: https://issues.apache.org/jira/browse/MESOS-1763
> Project: Mesos
> Issue Type: Epic
> Components: allocation, framework api, master
> Reporter: Vinod Kone
> Assignee: Benjamin Mahler
> Labels: mesosphere, multi-tenancy
>
> Currently, a framework can only obtain resources for a single allocation
> role. This design discusses allowing frameworks to obtain resources for
> multiple allocation roles.
> Use cases:
> * Allow an instance of a framework to be “multi-tenant” (e.g. Marathon,
> Aurora, etc). Currently, users run multiple instances of a framework under
> different roles to support multiple tenants.
> * Allow a framework to further leverage the resource allocation primitives
> within Mesos to ensure it has sufficient resource guarantees in place (e.g. a
> framework may want to set different guarantees amongst the tasks it needs to
> run, without necessarily being multi-tenant).
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
