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

["Michael Park (JIRA)" <ji...@apache.org>]

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

Michael Park updated MESOS-2363:
--------------------------------
    Description: 
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}}s.

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.

  was:
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 the {{SEV}}s. 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}}s.

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.


> 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}}s.
> 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)