[
https://issues.apache.org/jira/browse/MESOS-7746?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16119239#comment-16119239
]
Michael Park commented on MESOS-7746:
-------------------------------------
I think we can close this ticket as Won't Fix.
Given a cluster with a new master and old agents, consider what happens when a
framework opts into
reservation refinement vs hierarchical role. A framework opts into reservation
refinement by subscribing
with the {{RESERVATION_REFINEMENT}} capability. If we don't offer old agents'
resources to the framework,
it cannot continue its existing workload, say simply launching tasks using
top-level roles on old agents.
This behavior would be very disruptive to the framework and hence we avoid this.
On the other hand, a framework opts into hierarchical role simply by
subscribing to hierarchical roles.
There is no framework-wide capability that affects the existing workload. That
is, The top-level roles continue
to get offered resources from the old agents. This behavior is not disruptive
to the framework,
hence my claim that this ticket can be closed as Won't Fix.
h4. Enumeration of Scenarios
- {{HR}} - hierarchical role
- {{RR}} - reservation refinement
- {{-}} means non-capable, {{+}} means capable
1.3.x {{-HR}},{{-RR}}
<SHA> {{+HR}},{{-RR}}
1.4.x {{+HR}},{{+RR}}
- (A) We don't offer resources from a non-hierarchical-role-capable agent to
hierarchical roles (agent:{{-HR}},{{-RR}})
-* There cannot be any tasks that get launched with hierarchical roles on a
non-hierarchical-role-capable agent.
- An attempt to reserve resources or create volumes for a hierarchical role on
a non-hierarchical-role-capable agent
is rejected by the master. Because of (A), this can only happen through an
operator API. (agent:{{-HR}},{{-RR}})
- (B) We offer resources from a non-reservation-refinement-capable agent to
reservation-refinement-capable frameworks (agent:{{-/+HR}},{{-RR}})
- An attempt to create refined reservations on a
non-reservation-refinement-capable agent is rejected by the master.
Because of (A), this can only happen through an operator API,
(agent:{{-/+HR}},{{-RR}}), or if the framework gets offered
resources and attempts to create refined reservations on agents deployed at
some <SHA> between 1.3 and 1.4 that has {{+HR}},{{-RR}}.
Specifically, the only case where a framework needs access to the agent
capabilities in order to make the correct decision
is if there are agents deployed at some <SHA> between 1.3 and 1.4 that has
{{+HR}},{{-RR}}.
Overall, I think the current state is pretty good.
> Offer the resources from non-capable agents to hierarchical role
> ----------------------------------------------------------------
>
> Key: MESOS-7746
> URL: https://issues.apache.org/jira/browse/MESOS-7746
> Project: Mesos
> Issue Type: Task
> Reporter: Michael Park
> Assignee: Michael Park
> Priority: Blocker
>
> For refined reservations, we decided to offer non-capable resources to
> frameworks with {{RESERVATION_REFINEMENT}} since the resources can still be
> used to launch tasks and such. The master drops {{RESERVE}} requests that
> actually create refined reservations.
> This behavior should be consistent in hierarchical roles as well.
> Specifically, we should still offer the non-{{HIERARCHICAL_ROLE}} capable
> agents' resources to hierarchical roles, and have the master reject
> persistent volume creation requests.
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
