> On Dec. 4, 2019, 6:59 p.m., Benjamin Mahler wrote: > > Another observation from a subsequent review with: > > > > ``` > > static std::vector<ActionObject> growVolume( > > const Offer::Operation::GrowVolume& grow); > > > > static std::vector<ActionObject> shrinkVolume( > > const Offer::Operation::ShrinkVolume& shrink); > > ``` > > > > Why doesn't this patch just take the offer operations for launching tasks? > > > > ``` > > static std::vector<ActionObject> launch( > > const Offer::Operation::Launch& launch); > > > > static std::vector<ActionObject> launchGroup( > > const Offer::Operation::LaunchGroup& launchGroup); > > ``` > > > > That would look more consistent, and it would pull more logic out of the > > master code?
Unfortunately, this has to reflect an underlying inconsistency between authorizing LAUNCH operations and all the other operations. Currently, authorizing any non-LAUNCH operatiuon requires successful authorization for all the needed actions. However, tasks in LAUNCH operations are authorized independently; failure to authorize one task has no impact on launching other tasks from the same operation. If we are to change this behaviour, taking Launch operations as an argument would have perfect sense. Note, however, that switching to launch-all-or-nothing seems to be a major behaviour change. Even if we preserve the current paradigm, under which frameworks are informed about launch errors via task status updates, we will need to introduce a weird task status reason (`TaskStatus::REASON_TASK_FROM_THE_SAME_OPERATION_NOT_AUTHORIZED`?) - Andrei ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/71859/#review218918 ----------------------------------------------------------- On Jan. 2, 2020, 8 p.m., Andrei Sekretenko wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/71859/ > ----------------------------------------------------------- > > (Updated Jan. 2, 2020, 8 p.m.) > > > Review request for mesos, Benjamin Bannier and Benjamin Mahler. > > > Bugs: MESOS-10023 and MESOS-10056 > https://issues.apache.org/jira/browse/MESOS-10023 > https://issues.apache.org/jira/browse/MESOS-10056 > > > Repository: mesos > > > Description > ------- > > This is the first patch in the chain that extract Master code > generating Action-Object pairs into a dedicated ActionObject class, > thus seperating authz Object creation from feeding them into authorizer. > > This is a prerequisite to using ObjectApprover interface for > synchronous authorization of Scheduler API calls. > > > Diffs > ----- > > src/CMakeLists.txt ef9382dc77d37fed344b7267119f3251acd3088a > src/Makefile.am 111c156c8a7abc5ece04779e8ac8879a30c22dbf > src/master/authorization.hpp PRE-CREATION > src/master/authorization.cpp PRE-CREATION > src/master/master.hpp f97b085ae908278731acd326df68f9f381f09483 > src/master/master.cpp 14b90a5e276df055bb8a570331f27cab200c9869 > > > Diff: https://reviews.apache.org/r/71859/diff/3/ > > > Testing > ------- > > > Thanks, > > Andrei Sekretenko > >
