You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@mesos.apache.org by "Michael Park (JIRA)" <ji...@apache.org> on 2015/04/06 22:16:13 UTC

[jira] [Closed] (MESOS-2363) Reach a consensus on the terminology for Reservation levels.

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

Michael Park closed MESOS-2363.
-------------------------------
    Resolution: Won't Fix

The plan is to use the {{principal}} of the reserving entity in conjunction with the ACLs set by the operator to determine what actions are permitted for an operator or framework.

> Reach a consensus on the terminology for Reservation levels.
> ------------------------------------------------------------
>
>                 Key: MESOS-2363
>                 URL: https://issues.apache.org/jira/browse/MESOS-2363
>             Project: Mesos
>          Issue Type: Task
>            Reporter: Michael Park
>
> With the introduction of dynamic reservations, frameworks are given the ability to reserve unreserved resources for their role.
> We introduce different levels of reservations in order to give full admin control to the operators and also to prevent the frameworks to override operator-configured settings.
> The initial idea was to introduce a {{ReserverType}} with {{OPERATOR}} and {{FRAMEWORK}} to distinguish them. It turns out however that this idea doesn't work well if we want to allow an authorized framework with operator-level permissions to make operator-level changes. This leads to the idea that perhaps the names should be tied to the nature of reservation level, rather than the reserver.
> The following are a few ideas that have been suggested, would be great to compile a biggest list here and reach a consensus on our terminology.
> 1. Strong vs. Weak.
> This indicates the *strength* of the reservation, they're both dynamic but an operator or an authorized framework can make strong reservations whereas regular frameworks would make weak reservations.
> 2. System vs User.
> Suggested by [~cmaloney], this comes from the Linux world where sysadmins and authorized users can change system-level settings but regular users can change user-level settings.
> 3. Preset vs Runtime.
> Suggested by [~benjaminhindman], operators set preset-reservations and runtime reservations that can be changed by frameworks.
> 4. Reservation Levels.
> Similar to {{SEV}}. Indicate the strength of the reservation with a number. Maybe {{RSVN1}}, {{RSVN2}}, etc. If you have access to {{RSVN_N}}, you have access to all higher {{RSVN}}.
> I like the generality of (4), since if we were to add more strengths/levels of reservations, it would be the easiest to extend. Having said that, I also think that having good names would also be valuable.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)