> 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 > >