> 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.
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? > On June 13, 2013, 11:44 p.m., Vinod Kone wrote: > > src/master/master.cpp, lines 598-602 > > <https://reviews.apache.org/r/11206/diff/6/?file=304917#file304917line598> > > > > Don't we have to check this in re-register too? > > Thomas Marshall wrote: > Good point. This also brings up the question of what we should do if a > framework tries to reregister with a different role. We could check this by > sending FrameworkInfos from the slaves to the master when they reregister, > but that gets complicated if a framework reregisters before any slaves that > it has tasks running on reregister, or if a framework that doesn't have any > currently running tasks, and therefore none of the slaves have a copy of its > FrameworkInfo, reregisters. > > Thomas Marshall wrote: > We're going to leave the problem of frameworks reregistering with > different roles for when we do security. I was mostly thinking this is something that could go into the Master's registry. But I'm fine with punting on it for now. - Vinod ----------------------------------------------------------- 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 > >
