mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Bannier <bbann...@apache.org>
Subject Re: Review Request 63622: Provided handling for offer operation updates.
Date Tue, 07 Nov 2017 15:49:08 GMT

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




src/resource_provider/manager.cpp
Lines 430 (patched)
<https://reviews.apache.org/r/63622/#comment267608>

    `Call.UpdateOfferOperationStatus.latest_status` is `optional`; we should check if it is
set before using it.



src/resource_provider/message.hpp
Lines 51 (patched)
<https://reviews.apache.org/r/63622/#comment267609>

    Since we seem to mirror `Call.UpdateOfferOperationStatus` pretty closely here, let's use
an `Option<OfferOperationStatus> latestStatus`.



src/resource_provider/message.hpp
Lines 80 (patched)
<https://reviews.apache.org/r/63622/#comment267610>

    We should implement this.



src/slave/slave.cpp
Lines 6823-6824 (patched)
<https://reviews.apache.org/r/63622/#comment267612>

    Let's remove the reference to `used` from the comment.



src/slave/slave.cpp
Lines 6847 (patched)
<https://reviews.apache.org/r/63622/#comment267613>

    Let's do a contains check before the substraction.



src/slave/slave.cpp
Lines 6855 (patched)
<https://reviews.apache.org/r/63622/#comment267615>

    Let's not use `default` when switching over enum values; please enumerate all possible
values instead.



src/slave/slave.cpp
Lines 6861-6865 (patched)
<https://reviews.apache.org/r/63622/#comment267616>

    It seems this would mean that we drop status updates when we are in these states which
doesn't sound great.
    
    We do not start handling resource provider messages before we entered a running state,
but could enter another state later. Given that we don't have a status update manager for
offer operation status messaes yet, I believe it might make sense to fail over the agent should
we enter any of these states and add a `TODO` to revisit this code once we can reliably deliver
status updates.



src/tests/resource_provider_manager_tests.cpp
Lines 319 (patched)
<https://reviews.apache.org/r/63622/#comment267617>

    I believe we could we could use a `MockResourceProvider` here to simplify the test a bit.



src/tests/resource_provider_manager_tests.cpp
Lines 376 (patched)
<https://reviews.apache.org/r/63622/#comment267618>

    Not sure we need this, but if you want to keep it let's make it an `ASSERT` on the value
from the `event` instead of going through the assignment.


- Benjamin Bannier


On Nov. 7, 2017, 3:20 p.m., Jan Schlicht wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/63622/
> -----------------------------------------------------------
> 
> (Updated Nov. 7, 2017, 3:20 p.m.)
> 
> 
> Review request for mesos, Benjamin Bannier and Jie Yu.
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> When a resource provider has finished an offer operation, it will send
> a status update to the resource provider manager and subsequently to an
> agent. The agent then updates its internal bookkeeping and forwards the
> status update to the master.
> 
> 
> Diffs
> -----
> 
>   src/resource_provider/manager.cpp a878507d71a09a415d8a4573cf2b33c26c985451 
>   src/resource_provider/message.hpp 3c7c3f2baeb726e04edd6ffbb9784699d7afe521 
>   src/slave/slave.hpp df1b0205124555dcb6a0efa5c237f5e77fa2bdf7 
>   src/slave/slave.cpp c10823985154bac19f8952b94311a03b2b9b4ea1 
>   src/tests/resource_provider_manager_tests.cpp 4008b1c751d6227b99adef756e95174d7d8a62f2

> 
> 
> Diff: https://reviews.apache.org/r/63622/diff/1/
> 
> 
> Testing
> -------
> 
> make check
> 
> 
> Thanks,
> 
> Jan Schlicht
> 
>


Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message