> On April 22, 2015, 12:38 p.m., Alexander Rukletsov wrote: > > src/master/master.cpp, lines 2458-2459 > > <https://reviews.apache.org/r/32150/diff/5/?file=920953#file920953line2458> > > > > These two fields are optional, `principal` doesn't have a default. Do > > we need to check it? Can a framework without a principal reserve resources > > (the answer is no, I suppose, because in the current desgin a principal > > register resources, not a framework)? > > > > DO you mind adding tests for these cases? > > Michael Park wrote: > Thanks for this! Fixed and added a test `FrameworkMissingPrincipal`. > > Michael Park wrote: > Additionally, I've made changes to also reject unreservation requests > from frameworks without a `principal`. This makes it so that even without an > ACL, frameworks without a `principal` are completely out of the picture for > dynamic reservations.
That sounds right. > On April 22, 2015, 12:38 p.m., Alexander Rukletsov wrote: > > src/master/validation.cpp, line 555 > > <https://reviews.apache.org/r/32150/diff/5/?file=920955#file920955line555> > > > > Let's leave a comment here that `resource::validate` not only checks > > for integrity of the `resources` instance, but also for inconsistent state > > related to dynamic reservations. Since `resource::validate` doesn't have > > any comment it's unclear here that it does a related but non-obvious check > > for "*" role. > > Michael Park wrote: > Do you find that this is still related or helpful since our discussion > [here](https://reviews.apache.org/r/32140/#comment131682) along with the > listed valid states of the `Resource` object? I think it won't hurt leaving a pointer to the next guy who will be reading this code : ). > On April 22, 2015, 12:38 p.m., Alexander Rukletsov wrote: > > src/master/validation.cpp, lines 591-592 > > <https://reviews.apache.org/r/32150/diff/5/?file=920955#file920955line591> > > > > Shall we check framework and request principals are the same? > > Michael Park wrote: > No, at least not in the current specification. The `principal` indicates > the `principal` of the operator or framework that reserved the resources, > which means that we need to make sure that `Resource.Reservation.principal` > and `FrameworkInfo.principal` matches for the `Reserve` operation. On > `Unreserve`, we use the operator or framework's `principal` and the > `principal` set on the `Resource` object in conjunction with the "unreserve" > ACL to determine whether the unreserve operation is authorized. In the > absense of an ACL, we allow anyone to unreserve any resources. This is a > matter of authorization however, so we wouldn't check for the `prinicpal` > matching in `validate` even with ACLs. > In the absense of an ACL, we allow anyone to unreserve any resources. This is counter-intuitive for me, can we write this as a comment? Also, feel free to drop once done. - Alexander ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/32150/#review81139 ----------------------------------------------------------- On April 28, 2015, 10:43 p.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/32150/ > ----------------------------------------------------------- > > (Updated April 28, 2015, 10:43 p.m.) > > > Review request for mesos, Alexander Rukletsov, Ben Mahler, and Jie Yu. > > > Bugs: MESOS-2139 > https://issues.apache.org/jira/browse/MESOS-2139 > > > Repository: mesos > > > Description > ------- > > Handled reservation operations in `Master::_accept`. > > Added `validate` functions in `src/master/validation.{hpp,cpp}`. > > > Diffs > ----- > > src/master/master.cpp d42a6f321c88ec5d0418264bdda39d083ff54a7e > src/master/validation.hpp 2d7416c053f82d6316542fa9c35b0e7bc605abec > src/master/validation.cpp dc25995bf57397d42fcde458414f0402d19bf792 > src/tests/master_validation_tests.cpp > 4f2ad58c3ae0f611fb476c4d91a37dd6a5541395 > > Diff: https://reviews.apache.org/r/32150/diff/ > > > Testing > ------- > > make check > > > Thanks, > > Michael Park > >
