> On Jan. 29, 2019, 4:09 a.m., Benjamin Mahler wrote:
> > include/mesos/mesos.proto
> > Lines 1519 (patched)
> > <https://reviews.apache.org/r/69818/diff/1/?file=2121448#file2121448line1519>
> >
> >     I'm not sure if this gives much information to the reader, thoughts on 
> > the following?
> >     
> >     ```
> >     /**
> >      * Represents filters that allow a framework to control the
> >      * shape of offers that will be sent to its role(s). These
> >      * filters apply globally to any agent (unlike the existing
> >      * `DECLINE` filter, which is a time based resource subset
> >      * filter that only applies to the agent that was declined).
> >      */
> >     ```
> 
> Benjamin Bannier wrote:
>     I thought about something like that as well, but there is nothing in the 
> allocator interface enforcing it, e.g., an allocator could just ignore this 
> information.
>     
>     I'd suggest to not make promises here where it isn't much more than a 
> container.
> 
> Benjamin Mahler wrote:
>     From a practical standpoint, there are 0 alternative allocator 
> implementations (and that makes sense since it's not really the right 
> interface point). We already document a lot based on the assumption that an 
> allocator (i.e ours) is enforcing things like quota, drf, etc etc. So I think 
> we should just assume it and document accordingly.

Isn't it wrong to both provide an interface to use a custom allocator, and then 
make claims we cannot promise to fullfil in a public API? I believe treating 
the allocator module interface as unstable is one thing, but giving users the 
illusion that we control certain behavior a completely different one.

Suggest to keep the brief comment. Dropping.


- Benjamin


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


On Jan. 31, 2019, 4:15 p.m., Benjamin Bannier wrote:
> 
> -----------------------------------------------------------
> This is an automatically generated e-mail. To reply, visit:
> https://reviews.apache.org/r/69818/
> -----------------------------------------------------------
> 
> (Updated Jan. 31, 2019, 4:15 p.m.)
> 
> 
> Review request for mesos, Benjamin Mahler and Meng Zhu.
> 
> 
> Bugs: MESOS-9523
>     https://issues.apache.org/jira/browse/MESOS-9523
> 
> 
> Repository: mesos
> 
> 
> Description
> -------
> 
> This patch adds a new field to `FrameworkInfo` which can be used by
> frameworks to configure static, per-role resource requirements. We
> currently support specifying minimal allocatable resources which can
> e.g., be interpreted by allocators to filter out resources not relevant
> to frameworks, or make allocations below globally configured minimal
> allocatable resources for particular frameworks.
> 
> We use a new message `ResourceQuantities` to specify resource
> requirements. This class is modelled after the internal class of the
> same name, and we provide a conversion from the API to the internal
> type.
> 
> 
> Diffs
> -----
> 
>   include/mesos/mesos.proto 9d5c2b53164adb44eb4a6f12a507e009bd607940 
>   include/mesos/v1/mesos.proto aef31eb5b8781182d3f42d935b12470b319027ed 
>   src/common/resource_quantities.hpp 11eb426104577bbbbb7977c2307df3e4917085cd 
>   src/common/resource_quantities.cpp 320983929cd7d14973c4b98d6ed5338de690ff5f 
> 
> 
> Diff: https://reviews.apache.org/r/69818/diff/5/
> 
> 
> Testing
> -------
> 
> `make check`
> 
> 
> Thanks,
> 
> Benjamin Bannier
> 
>

Reply via email to