> On Jan. 12, 2016, 6:43 a.m., Benjamin Bannier wrote:
> > src/master/master.cpp, line 3084
> > <https://reviews.apache.org/r/42086/diff/3/?file=1192385#file1192385line3084>
> >
> >     Since there's a clean separation among offers and inverse offers, it 
> > seems we could begin logging unknown offers (probably: at some low prio).
> 
> Joseph Wu wrote:
>     Each of the validation functions already perform this check.  But the 
> error message is `"Offer " + stringify(offerId) + " is no longer valid"`, 
> presumably because re-accepting an offer is more likely than accepting a 
> random unknown `OfferID`.  
>     This error is, in my diff, printed right after the validation function 
> returns an error.
>     
>     In light of this, do you think it's still necessary to print each unknown 
> offer?
> 
> Benjamin Bannier wrote:
>     True, the validation might return an Error if the offer is no longer 
> valid. I am just wondering about the invariants here:
>     
>     * if an offer could go away concurrently here (probably not) we should 
> still emit an error, e.g., to a log
>     * if the offer will always be valid we should just `CHECK` to be explicit.
>     
>     Does that make sense?
> 
> Joseph Wu wrote:
>     For each of your points:
>     
>     * Master, being a libprocess actor, will not remove offers racily in the 
> middle of this function.  So if `offers::validate` doesn't error, all the 
> checked offers will exist.
>     * If we wanted to be super explicit, we'd end up with some 
> not-necessarily easier-to-read code.  For example, to properly implement a 
> `CHECK` (for just regular offers):
>     ```
>     vector<OfferID> offerIds; // Assume this is filled in...
>     
>     const Option<Error> offerError = validation::offer::validate(offerIds, 
> this, framework);
>     
>     if (offerError.isSome()) {
>       LOG(WARNING) << "ACCEPT call used invalid offers '" << offerIds << "': 
> " << offerError.get().message;
>       
>       // We still need to recover the invalid offers, so we need to do this 
> at some point.
>       foreach (const OfferID& offerId, offerIds) {
>         Offer* offer = getOffer(offerId);
>         if (offer != NULL) {
>           allocator->recoverResources(
>               offer->framework_id(),
>               offer->slave_id(),
>               offer->resources(),
>               None());
>     
>           removeOffer(offer);
>         }
>       }
>     } else {
>       Resources offeredResources;
>       Option<SlaveID> slaveId = None();
>     
>       // Compute offered resources and remove the offers.
>       foreach (const OfferID& offerId, offerIds) {
>         Offer* offer = getOffer(offerId);
>         
>         // Here's the check!  Since `offerError` is `None()`, all the offers 
> should exist.
>         CHECK(offer != NULL);
>         
>         slaveId = offer->slave_id();
>         offeredResources += offer->resources();
>     
>         removeOffer(offer);
>       }
>     }
>     
>     // The rest of the function...
>     ```

After double-checking the diff, I could add a `CHECK` for inverse offers, but 
not for regular offers.


> On Jan. 12, 2016, 6:43 a.m., Benjamin Bannier wrote:
> > src/master/master.cpp, line 3118
> > <https://reviews.apache.org/r/42086/diff/3/?file=1192385#file1192385line3118>
> >
> >     Since there's a clean separation among offers and inverse offers, it 
> > seems we could begin logging unknown offers (probably: at some low prio).

This will be logged as part of `validation::offer::validate`.


- Joseph


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


On Jan. 12, 2016, 2:20 p.m., Joseph Wu wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/42086/
> -----------------------------------------------------------
> 
> (Updated Jan. 12, 2016, 2:20 p.m.)
> 
> 
> Review request for mesos, Ben Mahler, Artem Harutyunyan, and Joris Van 
> Remoortere.
> 
> 
> Bugs: MESOS-4301
>     https://issues.apache.org/jira/browse/MESOS-4301
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> Adds `validation::offer::inverse::validate` to validate inverse offers along 
> the same lines as `validation::offer::validate`, except `SlaveId` is not 
> validated for inverse offers.
> 
> Fixes and refactors `Master::accept` to allow `ACCEPT` calls that contain 
> both offers and inverse offers.
> Also tweaks `Master::accept` to not print a misleading log line "ACCEPT call 
> used invalid offers ..." when the call only includes inverse offers.
> 
> 
> Diffs
> -----
> 
>   include/mesos/type_utils.hpp efe2b1de0c277db62d7f7cc5ff1cd9143b9f632a 
>   src/common/type_utils.cpp 76f48f6a1f5467db032ded8acd296d03353b4172 
>   src/master/master.hpp f02d165874fa8023675e545793de699aeecae29b 
>   src/master/master.cpp 5268408fc63a28afabc27cba96d3ecb360608a65 
>   src/master/validation.hpp 380b40279faf180a6f401a5e28280b601dbc648c 
>   src/master/validation.cpp 6a43bce5b7df6a9d939245c4726d060fa19eb305 
> 
> Diff: https://reviews.apache.org/r/42086/diff/
> 
> 
> Testing
> -------
> 
> make check
> 
> # Ran the following and checked for blank output:
> bin/mesos-tests.sh --gtest_filter="*Inverse*Offer*" --verbose 2>&1 /dev/null 
> |  grep "ACCEPT call used invalid offers"
> 
> # Check new test for flakiness:
> bin/mesos-tests.sh --gtest_filter="*OffersAndInverseOffers" 
> --gtest_repeat=1500 --gtest_break_on_failure
> 
> 
> Thanks,
> 
> Joseph Wu
> 
>

Reply via email to