[ 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)