[
https://issues.apache.org/jira/browse/MESOS-7651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Benjamin Mahler updated MESOS-7651:
-----------------------------------
Description:
Currently, when a framework creates a reservation or a persistent volume, and
it wants exclusive access to this volume or reservation, it must take a few
steps:
* Ensure that no other frameworks are running within the reservation role (or
the other frameworks are co-operative).
* With hierarchical roles, frameworks must also ensure that the role is a leaf
so that no descendant roles will have access to the reservation/volume. This
could be done by generating a role (e.g. eng/kafka/<instance id>).
It's not easy for the framework to ensure these things, since role ACLs are
controlled by the operator.
We should consider a more direct way for a framework to ensure that their
reservation/volume cannot be shared. E.g. by binding it to their framework id
(perhaps re-using roles for this rather than introducing something new?)
We should also consider binding the reservation / volumes, much like other
objects (tasks, executors), to the framework's lifecycle. So that if the
framework is removed, the reservations / volumes it left behind are cleaned up.
was:
Currently, when a framework creates a reservation or a persistent volume, and
it wants exclusive access to this volume or reservation, it must take a few
steps:
* Ensure that no other frameworks are running within the reservation role (or
the other frameworks are co-operative).
* With hierarchical roles, frameworks must also ensure that the role is a leaf
so that no descendant roles will have access to the reservation/volume. This
could be done by generating a role (e.g. eng/kafka/<instance id>).
It's not easy for the framework to ensure these things, since role ACLs are
controlled by the operator.
We should consider a more direct way for a framework to ensure that their
reservation/volume cannot be shared. E.g. by binding it to their framework id
(perhaps re-using roles for this rather than introducing something new?)
> Consider a more explicit way to bind reservations / volumes to a framework.
> ---------------------------------------------------------------------------
>
> Key: MESOS-7651
> URL: https://issues.apache.org/jira/browse/MESOS-7651
> Project: Mesos
> Issue Type: Improvement
> Reporter: Benjamin Mahler
>
> Currently, when a framework creates a reservation or a persistent volume, and
> it wants exclusive access to this volume or reservation, it must take a few
> steps:
> * Ensure that no other frameworks are running within the reservation role (or
> the other frameworks are co-operative).
> * With hierarchical roles, frameworks must also ensure that the role is a
> leaf so that no descendant roles will have access to the reservation/volume.
> This could be done by generating a role (e.g. eng/kafka/<instance id>).
> It's not easy for the framework to ensure these things, since role ACLs are
> controlled by the operator.
> We should consider a more direct way for a framework to ensure that their
> reservation/volume cannot be shared. E.g. by binding it to their framework id
> (perhaps re-using roles for this rather than introducing something new?)
> We should also consider binding the reservation / volumes, much like other
> objects (tasks, executors), to the framework's lifecycle. So that if the
> framework is removed, the reservations / volumes it left behind are cleaned
> up.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
