-----------------------------------------------------------
This is an automatically generated e-mail. To reply, visit:
https://reviews.apache.org/r/39988/#review108510
-----------------------------------------------------------



src/master/http.cpp (lines 1037 - 1040)
<https://reviews.apache.org/r/39988/#comment167962>

    Let's not lose the comment on the left.



src/master/http.cpp (lines 1037 - 1041)
<https://reviews.apache.org/r/39988/#comment167963>

    It looks like the `repair` here is to catch the case where 
`authorizeReserveResources` __fails__ on an invalid reserve request.
    
    In https://reviews.apache.org/r/39987/ I asked whether the validation step 
needs to be within the authorization step. I still think it should be 
separated. If we were to separate them out, with Jie's suggestion below in 
mind, this could look like:
    
    ```cpp
      return master->authorizeReserveResources(operation, principal)
        .then(defer(master->self(), [=](bool authorized) -> Future<Response> {
          if (!authorized) {
            return Unauthorized("Mesos master");
          }
          Option<Error> error =
            validation::operation::validate(operation.reserve(), None(), 
principal);
          if (error.isSome()) {
            return BadRequest("Invalid RESERVE operation: " + 
error.get().message);
          }
          return _operation(slaveId, resources.flatten(), operation);
        }));
    ```



src/master/http.cpp (lines 2307 - 2317)
<https://reviews.apache.org/r/39988/#comment167965>

    With Jie's suggestion, we don't need this anymore. However, I would like to 
point out some weirdness here for future reference.
    
    Since the `_operation` is only being used with `.then` or in a direct call, 
the `authorized` can/should be `bool` rather than `Future<bool>`. Take a look 
at `_teardown`. The reason this works as-is is because `bool` is implicitly 
convertible to `Future<bool>`.
    
    With that in mind, we can then observe that the `if 
(!authorized.isReady())` is actually dead code. Whatever error handling that 
was intended to be done in that if-clause actually gets caught by the `repair` 
above instead.


- Michael Park


On Nov. 30, 2015, 8:46 p.m., Greg Mann wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/39988/
> -----------------------------------------------------------
> 
> (Updated Nov. 30, 2015, 8:46 p.m.)
> 
> 
> Review request for mesos, Adam B, Jie Yu, Michael Park, and Till Toenshoff.
> 
> 
> Bugs: MESOS-3062
>     https://issues.apache.org/jira/browse/MESOS-3062
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Added authorization for dynamic reservation master endpoints.
> Note: this review is continued from https://reviews.apache.org/r/37126/
> 
> 
> Diffs
> -----
> 
>   src/master/http.cpp 9d729ef7f7d7ad6185934648f833e4f8a4f0a123 
>   src/master/master.hpp 96951e766de32842197506504e5ac67a2caa3efe 
>   src/tests/reservation_endpoints_tests.cpp 
> f30ff8bc6a3e9773437fa7fd7c8f569b7d7e2d9d 
> 
> Diff: https://reviews.apache.org/r/39988/diff/
> 
> 
> Testing
> -------
> 
> This is the fourth in a chain of 5 patches. Added new reservation endpoints 
> tests to validate authorization of reserve and unreserve operations using 
> ACLs. `make check` was run to test after all patches were applied.
> 
> 
> Thanks,
> 
> Greg Mann
> 
>

Reply via email to