mesos-reviews mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Benjamin Mahler <bmah...@apache.org>
Subject Re: Review Request 72897: Allowed `OfferConstraintsFilter::create()` to return an empty `Result`.
Date Wed, 23 Sep 2020 19:21:25 GMT


> On Sept. 22, 2020, 8:50 p.m., Benjamin Mahler wrote:
> > Hm.. can you clarify what this gives us?
> 
> Andrei Sekretenko wrote:
>     Now I think I need your input here.
>     If we decide to keep in a long term a guarantee that specifying default-constructed
OfferConstraints is equivalent to not specifying any constraints at all, we are going to have
a certain weirdness internally: right now, there are two functionally equivalent ways to specify
to the allocator that the framework has **no offer constraints filtering**.
>     
>     One way is to set the `offerConstraintsFilter` in the framework's allocator options
to `None`; another is to pass a filter constructed from empty constraints.
>     My intention was to eliminate one of these two ways. This patch gets rid of the second
one (filters that are known to be a no-op are not created).
>     
>     However, on the second thought, just making a filter non-optional might make things
simpler.
>     
>     I've benchmarked the default (no constraints) case and failed to find any difference
between allocator's `struct Framework` always having a non-optional empty filter vs an empty
Option.
>     No difference - despite of the fact that the first thing in the inner allocation
loop is the agent filtering check `offerConstraintsFilter.isSome() && offerConstraintsFilter->isAgentExcluded(..)`
(the version that makes filter non-optional drops `isSome()`).
>     
>     What do you think about just making the filter obligatory (and default-constructable,
equivalent to constructing form default `OfferConstraints`)?
> 
> Andrei Sekretenko wrote:
>     sorry, typo: s/constructing form/constructing from/

Removing the optionality sounds good, and was something I wondered back when seeing the `offerConstraintsFilter.isSome()
&& offerConstraintsFilter->isAgentExcluded(..)` logic.

The only value I saw from optionality is us knowing (via endpoints) whether the framework
is setting the field (and if not set, inferring that the framework is not constraint-capable).
i.e. being able to distinguish between a framework that is not constraint capable vs a framework
that is constraint capable but doesn't have any constraints to set and therefore uses an empty
OfferConstraints.

Thinking about it more though, I don't know that we would see a constraint-capable framework
setting it to an empty value very often? Would we?
I'm also not sure whether constraint-capable frameworks will set the field to empty vs not
set it. If that's not done consistently then we wouldn't get much value from distinguishnig
those cases in the endpoints.

So, I think just removing optionality seems simplest!


- Benjamin


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


On Sept. 22, 2020, 6:05 p.m., Andrei Sekretenko wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/72897/
> -----------------------------------------------------------
> 
> (Updated Sept. 22, 2020, 6:05 p.m.)
> 
> 
> Review request for mesos and Benjamin Mahler.
> 
> 
> Bugs: MESOS-10189
>     https://issues.apache.org/jira/browse/MESOS-10189
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This patch makes it possible for the offer constraint filter creation
> to return `None()` in cases when specified offer constraints would
> result in creating a no-op `OfferConstraintsFilter` that would never
> filter out anything, and actually implements this special handling
> for an `OfferConstraints` message with an empty role constraints map.
> 
> 
> Diffs
> -----
> 
>   include/mesos/allocator/allocator.hpp 6d67d5d5c32c1f18cdf6f925d747156c2bbc7820 
>   src/master/allocator/mesos/offer_constraints_filter.cpp 441ebc10219bf3bd623fac2bb08945ea9deb7ea3

>   src/master/master.cpp fefa72d338384b6ccb1bcbbed7192713411035db 
>   src/tests/master/offer_constraints_filter_tests.cpp f80d56c89d937b6a1b261202adefb37a1519bf0d

> 
> 
> Diff: https://reviews.apache.org/r/72897/diff/1/
> 
> 
> Testing
> -------
> 
> 
> Thanks,
> 
> Andrei Sekretenko
> 
>


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