> On March 17, 2014, 5:38 a.m., Adam B wrote: > > include/mesos/mesos.proto, lines 483-485 > > <https://reviews.apache.org/r/18730/diff/4/?file=520216#file520216line483> > > > > How does this play along with 'permissive'?
There is a difference between a field not being *set* and a field being *set* but empty. I've updated the comments to reflect this. Let me know if that clears things up. > On March 17, 2014, 5:38 a.m., Adam B wrote: > > include/mesos/mesos.proto, lines 514-515 > > <https://reviews.apache.org/r/18730/diff/4/?file=520216#file520216line514> > > > > I'm confused about how this should read. > > When I think of ACLs, I think Subject(s) can/cannot Action Object(s), > > which here would read that these principals are AllocatableTo this Role. > > However, in protobuf Ser/De, it will read more like role.role = > > "roleX"; and role.allocatable_to.principals = "foo,bar"; So, the logic > > reads the reverse (object.action.subject). Is that weird to anybody else? The most common definition for an ACL is a set of restrictions that you set on an object (see: http://en.wikipedia.org/wiki/Access_control_list, http://docs.aws.amazon.com/AmazonS3/latest/dev/ACLOverview.html). With that in mind, I've used "Object" to be in the fore front of an ACL. While this plays nicely with URL it is admittedly a bit awkward for Role and User. If you imagine how the JSON would look like for a person setting up ACLs maybe this is a bit more intuitive. { 'permissive' : true 'urls' : [ { 'url' : '/stats.json', 'get' : { 'ips' : {'values' : [127.0.0.1, 192.168.1.1] }, 'hosts' : {'values' : ["localhost"]} } } ] 'roles' : [ 'role' : 'ads', 'allocatable_to' : { 'principals' : {'values' : ['Aurora', 'Marathon']} } ] } > On March 17, 2014, 5:38 a.m., Adam B wrote: > > include/mesos/mesos.proto, line 515 > > <https://reviews.apache.org/r/18730/diff/4/?file=520216#file520216line515> > > > > What is 'principals' supposed to represent here? Slaves? So that slave1 > > and slave2 are allocatable_to a particular role (e.g. marketing)? Maybe > > 'principals' should be named something more explicit. 'principal' is the framework principal that we have authenticated. See "Credential.Principal". This is essentially saying which framework principals get resource offers for a certain resource reservation role. See the JSON above for an example. > On March 17, 2014, 5:38 a.m., Adam B wrote: > > include/mesos/mesos.proto, line 518 > > <https://reviews.apache.org/r/18730/diff/4/?file=520216#file520216line518> > > > > Would we ever want to encode multiple roles in the same Role message? > > If so, perhaps we should instead have "repeated string roles". > > It's much easier to change from a repeated field to > > optional/deprecated, but not so with a required field. Again, per definition of ACL, we don't club objects. In your example, each role will get its own ACL. > On March 17, 2014, 5:38 a.m., Adam B wrote: > > include/mesos/mesos.proto, lines 527-528 > > <https://reviews.apache.org/r/18730/diff/4/?file=520216#file520216line527> > > > > Subject is LaunchableBy Object (principals are launchable_by user), or > > v.v. user.launchable_by.principals? See above. > On March 17, 2014, 5:38 a.m., Adam B wrote: > > include/mesos/mesos.proto, line 528 > > <https://reviews.apache.org/r/18730/diff/4/?file=520216#file520216line528> > > > > Again, what are the 'principals'? Frameworks? I can understand if we're > > saying that these frameworks are launchable_by this user. Yes. frameworks. > On March 17, 2014, 5:38 a.m., Adam B wrote: > > include/mesos/mesos.proto, line 531 > > <https://reviews.apache.org/r/18730/diff/4/?file=520216#file520216line531> > > > > Would we ever want to encode multiple users in the same User message? > > "repeated string users". No. See above. - Vinod ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18730/#review37339 ----------------------------------------------------------- On March 15, 2014, 12:45 a.m., Vinod Kone wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18730/ > ----------------------------------------------------------- > > (Updated March 15, 2014, 12:45 a.m.) > > > Review request for mesos, Adam B, Benjamin Hindman, and Niklas Nielsen. > > > Bugs: MESOS-911 > https://issues.apache.org/jira/browse/MESOS-911 > > > Repository: mesos-git > > > Description > ------- > > See summary. > > > Diffs > ----- > > include/mesos/mesos.proto 37f8a7fcd23d467b1274c46c405b836510afbd49 > src/Makefile.am ce7913be8432290a01fdcdede0fb9b5233745031 > src/authorizer/authorizer.hpp PRE-CREATION > src/tests/authorization_tests.cpp PRE-CREATION > src/tests/master_contender_detector_tests.cpp > 8da7420e18c7a960b566fae13a5975857eb777ee > > Diff: https://reviews.apache.org/r/18730/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Vinod Kone > >
