Michael Park created MESOS-2363:
-----------------------------------
Summary: 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 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
