----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/56178/#review164477 -----------------------------------------------------------
There's a difference between backwards compatibility with frameworks that are not capable of multi-role and backwards compatibility with authorizer modules that are not multi-role capable. Let's not confuse the two. src/master/master.cpp (line 2177) <https://reviews.apache.org/r/56178/#comment236234> I find it helpful to mention when the deprecation cycle started (release date or version), so we can compute when it ends, based on our current policy. src/master/master.cpp (line 2178) <https://reviews.apache.org/r/56178/#comment236235> What does the framework's capability have to do with whether a custom authorizer can support multi-role authorization? If I have an old authorizer module, and multi-role (phase 1) capable frameworks, I will only be able to authorize frameworks with a single role (regardless of capability). For a multi-role framework, I could authorize a single role from the list, but that essentially provides a back-door for those frameworks to use other roles. Or I could call the authorizer multiple times, one for each role. But we wouldn't want to do that for multi-role capable authorizers. Maybe we need the concept of "module capabilites" now too? Am I overthinking this? - Adam B On Feb. 7, 2017, 12:32 a.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/56178/ > ----------------------------------------------------------- > > (Updated Feb. 7, 2017, 12:32 a.m.) > > > Review request for mesos, Adam B, Alexander Rojas, and Benjamin Mahler. > > > Bugs: MESOS-7022 > https://issues.apache.org/jira/browse/MESOS-7022 > > > Repository: mesos > > > Description > ------- > > This updates the local authorizer so that MULTI_ROLE frameworks can be > authorized. > > For non-MULTI_ROLE frameworks we continue to support use of the > deprecated 'value' field in the authorization request's 'Object'; > however for MULTI_ROLE frameworks the 'value' field will not be set, > and authorizers still relying on it should be updated to instead use > the object's 'framework_info' field to extract roles to authorize > against from. > > > Diffs > ----- > > src/authorizer/local/authorizer.cpp > b98e1fcdf2ee5ec1f6ac0be6f8accdefaa390a09 > src/master/master.cpp 98c39b279e7b9830d02efc8ec6a4469afc15d62a > > Diff: https://reviews.apache.org/r/56178/diff/ > > > Testing > ------- > > Tested on various configurations in internal CI. > > > Thanks, > > Benjamin Bannier > >
