> 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
> 
>

Reply via email to