> On Dec. 8, 2015, 3:02 p.m., Yong Qiao Wang wrote: > > include/mesos/master/allocator.hpp, line 101 > > <https://reviews.apache.org/r/41075/diff/1/?file=1155806#file1155806line101> > > > > When allocator initialize, their should be no active frameworks in > > mesos, can we consider to remove this parmeter from initialize()? and can > > initialize role-related information in addFramework(). > > Neil Conway wrote: > Hmmm -- I think it is better as written. Right now, weights are static > and set at initialization-time, so I think it makes more sense for them to be > parameters of `initialize`, not `addFramework`. (When we do dynamic weights > we'll need to reconsider this, but even then, I don't think passing weights > to `addFramework` will be the right API). > > Yong Qiao Wang wrote: > For long term solution in Implicit Roles, --roles and --weights should be > removed, so weights parameter will only have one default value(*,1). so it is > make sence to remove this parameter from initialize (),and when framework > register, we can add its role and the corresponding weight into allocator, > then they can become active. > > Adam B wrote: > Even if we eliminate --weights, we'll be persisting the weights map to > the registry, and on failover to a new master or on a new master's startup, > it will recover the weights from the registry. It seems reasonable to me that > after recovering the weights, the master could start the allocator with the > newly recovered weights, rather than have to add them after allocator > initialization. > > Neil Conway wrote: > Note also that a role's weight is required even _before_ `addFramework`, > because the weight of a role with quota set is relevant even if the role has > no registered frameworks. So I think specifying the weight in `addFramework` > isn't right. We could consider replacing the `initialize` argument with a > separate `updateWeight` allocator API call, but I'm inclined to defer that > until the dynamic weight work is actually done.
Neil, can you please clarify a little more about why the weight of a role with quota set is relevant even if the role has no registered frameworks? - Qian ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/41075/#review109287 ----------------------------------------------------------- On Dec. 8, 2015, 4:33 p.m., Neil Conway wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/41075/ > ----------------------------------------------------------- > > (Updated Dec. 8, 2015, 4:33 p.m.) > > > Review request for mesos, Adam B, Alexander Rukletsov, Benjamin Hindman, Greg > Mann, and Yong Qiao Wang. > > > Bugs: MESOS-4085 > https://issues.apache.org/jira/browse/MESOS-4085 > > > Repository: mesos > > > Description > ------- > > Changed the behavior of the master when the `--roles` flag is NOT > specified. Previously, this would allow only the `*` role to be used. Now, > omitting `--roles` means that any role can be used. This is called "implicit > roles". Configuring which principals can perform operations as which roles > should be done using ACLs in the authorization system. > > Note that this changes the behavior of the system when `--roles` is not > specified. This is likely acceptable: if the operator didn't specify `--roles` > in prior versions of Mesos, they were likely not using roles or authorization > at > that time. > > Another minor behavioral change is that the "/roles" endpoint will now only > return results for currently "active" roles (those with one or more registered > frameworks). > > The `--roles` flag is now considered deprecated and will be removed in a > future > version of Mesos. > > > Diffs > ----- > > include/mesos/master/allocator.hpp 619ef01c3a7d640560653cfc1838dd09046d1da0 > include/mesos/master/allocator.proto > 702f56f56c3b1331613cecf26522986f6b572f8c > src/master/allocator/mesos/allocator.hpp > 97ee80726ad155917811265a983258b0165d3451 > src/master/allocator/mesos/hierarchical.hpp > 99c742906874c30c39c159e58a65277ade3c07fd > src/master/allocator/mesos/hierarchical.cpp > 5da825a1d578a9ee40b4985378fddb3c5fb3b416 > src/master/http.cpp 9097eda47558fb5306af5a61b464937d7ab34e83 > src/master/master.hpp 4683fa542a740f9a0b80fff7fbe0e63ec66266f2 > src/master/master.cpp 953fa4f14929581b226a7e27d30aea7a5aa1fd7c > src/master/quota_handler.cpp b209da42ace752953686eeda9577007a33556d5d > src/tests/allocator.hpp c7670525765491fe931a4ee38446fa7e9d79af42 > src/tests/hierarchical_allocator_tests.cpp > fb214a829a57529d3f5c49730ae9733f53e622ca > > Diff: https://reviews.apache.org/r/41075/diff/ > > > Testing > ------- > > "make check" on OSX 10.10 and Ubuntu 15.10; `--gtest_repeat=1000` for the > more likely role-related tests. > > TODOs: > > * Update documentation > * Add tests for allocation behavior for weights + implicit roles > * Add tests for quota + implicit roles? > > Notes: > > * There's two places where we use manual `new`/`delete` where a `unique_ptr` > would probably be nicer. I'm inclined to leave this as-is for now though > (making use of unique_ptr is a broader issue). > > > Thanks, > > Neil Conway > >