> On Dec. 17, 2015, 1:17 a.m., Michael Park wrote:
> > src/master/http.cpp, lines 1000-1006
> > <https://reviews.apache.org/r/41472/diff/1/?file=1167118#file1167118line1000>
> >
> > Hm, should this be added to `validation::operation::validate` instead?
> > That way if/when we have frameworks reserving for specific roles, it'll
> > just work?
>
> Neil Conway wrote:
> I thought about that, but it would require passing either the role
> whitelist or a pointer to the master itself into the
> `validation::operation::validate()` -- both of which seemed like they would
> be regrettable changes to make. What do you think?
>
> Adam B wrote:
> I'm fine with it as is, but I'll wait for @mcypark to make the call.
To me, it seems natural to have to pass whatever state is necessary to perform
validation properly.
The `offer` validation for example takes `Master*` since it needs some
information from the master.
```cpp
// Validates the given offers.
Option<Error> validate(
const google::protobuf::RepeatedPtrField<OfferID>& offerIds,
Master* master,
Framework* framework);
```
Ideally, we would pass along something more constrained than "all of master",
similar to `CreateVolume` validation.
```cpp
// Validates the CREATE operation. We need slave's checkpointed
// resources so that we can validate persistence ID uniqueness.
Option<Error> validate(
const Offer::Operation::Create& create,
const Resources& checkpointedResources);
```
Here, `checkpointedResources` is a part of the master state. Passing along the
role whitelist would be similar to this case.
What do you think?
- Michael
-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/41472/#review110830
-----------------------------------------------------------
On Dec. 16, 2015, 10:48 p.m., Neil Conway wrote:
>
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/41472/
> -----------------------------------------------------------
>
> (Updated Dec. 16, 2015, 10:48 p.m.)
>
>
> Review request for mesos, Adam B and Michael Park.
>
>
> Bugs: MESOS-4143
> https://issues.apache.org/jira/browse/MESOS-4143
>
>
> Repository: mesos
>
>
> Description
> -------
>
> Also added a test that dynamic reservations via the "/reserve" endpoint are
> allowed when using implicit roles.
>
>
> Diffs
> -----
>
> src/master/http.cpp 8dfd67f7d51b8395953d6beb77b2d71bc538eacd
> src/tests/reservation_endpoints_tests.cpp
> b8edd6fafedd4c2221a8d19c1ebc71254071a8c7
>
> Diff: https://reviews.apache.org/r/41472/diff/
>
>
> Testing
> -------
>
> make check
>
>
> Thanks,
>
> Neil Conway
>
>