> On June 13, 2013, 11:44 p.m., Vinod Kone wrote: > > src/master/master.cpp, lines 248-251 > > <https://reviews.apache.org/r/11206/diff/6/?file=304917#file304917line248> > > > > Why do we always want to allow a default role? > > Thomas Marshall wrote: > We did this to minimize the impact of these changes on people who don't > care about roles or hierarchical allocation, but I agree that we don't always > want a default role. Maybe the solution is to add the default role if no > --role flag is present, and then allow people who use roles to turn on the > default role by including a '*' in their --roles flag. > > Thomas Marshall wrote: > Ben and I talked, and we're going to leave the default role turned on all > of the time. If people don't want it, they can set all of the resources on > all of the slaves to be reserved for specific roles (which they would have to > do anyways without a default role) and get the same effect, but we figure > most people will want the default role most of the time precisely because it > doesn't require you to mark all of the resources in the entire cluster with a > specific role. > > Vinod Kone wrote: > I am mainly concerned about the possibility of disallowing a default > role. I though the roles were ever gonna be specified on the master's cmd > flags. But sounds like there is a complementary role flag for slaves that > allows us to disable the default role? I guess thats in a different review?
TL;DR; I don't think we'd ever want to disallow a default role. Having a _special_ "default" role (i.e., '*') enables launching frameworks without requiring reconfiguring the master. I don't think we want to configure reservations for every possible authenticated user. Rather, if a user runs in the "default" role they can be allocated whatever resources are available to the default role (which may be none!) without requiring some human intervention first. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/11206/#review21872 ----------------------------------------------------------- On June 18, 2013, 9:12 p.m., Thomas Marshall wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/11206/ > ----------------------------------------------------------- > > (Updated June 18, 2013, 9:12 p.m.) > > > Review request for mesos and Benjamin Hindman. > > > Description > ------- > > Previously when we were doing hierarchical allocation by user, we created and > removed user pools for allocation based on what users had frameworks > currently running in the cluster. However, with the role abstraction it makes > sense to have more persistence than that, especially once we add weights - if > you set the weight for a role, you want the allocator to remember it even if > there aren't any frameworks for that role currently running. > > So, I decided that it made sense to create a concept of specific roles that > are allowable in the cluster. With this patch, its only possible to pass > roles in to the master as a command line flag (to ease what I assume will be > the common case - clusters with relatively static sets of roles), but a > future wdrf patch will add http endpoints to add, remove, and update roles. > > This patch also enforces that frameworks register with valid role (this won't > affect people who don't care about roles, since there's always the "*" role, > which is the default for frameworks that don't specify a role). > > > This addresses bug MESOS-504. > https://issues.apache.org/jira/browse/MESOS-504 > > > Diffs > ----- > > src/master/allocator.hpp 78c75bb > src/master/flags.hpp f4ce8c1 > src/master/hierarchical_allocator_process.hpp 1048a28 > src/master/master.hpp 86c5232 > src/master/master.cpp 60c6d4f > src/messages/messages.proto 2c196ee > src/tests/allocator_tests.cpp 32f0a90 > src/tests/allocator_zookeeper_tests.cpp 1daaecd > src/tests/mesos.hpp fca41aa > src/tests/resource_offers_tests.cpp 3d5f02d > > Diff: https://reviews.apache.org/r/11206/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Thomas Marshall > >
