> 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? > > Alexander Rukletsov wrote: > I think it won't hurt leaving a pointer to the next guy who will be > reading this code : ).
I've updated the comment for `Resource::validate` like so: ``` A Resource object is valid if it has a name, a valid type, - // i.e. scalar, range, or set, and has the appropriate value set. + // i.e. scalar, range, or set, has the appropriate value set, and + // a valid (role, reservation) pair for dynamic reservation. ``` > 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. > > Alexander Rukletsov wrote: > > 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. I've left the following comment in the `validate` function for `Unreserve`: ``` // NOTE: We don't check that 'FrameworkInfo.principal' matches // 'Resource.ReservationInfo.principal' here because the authorization // depends on the "unreserve" ACL which specifies which 'principal' can // unreserve which 'principal's resources. In the absense of an ACL, we allow // any 'principal' to unreserve any other 'principal's resources. ``` - Michael ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/32150/#review81139 ----------------------------------------------------------- On May 2, 2015, 12:27 a.m., Michael Park wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/32150/ > ----------------------------------------------------------- > > (Updated May 2, 2015, 12:27 a.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 > ----- > > include/mesos/resources.hpp 56affd45e1e71e96ff5778b43271f81b9b9a9e4d > 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 > >
