> 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. > > Benjamin Bannier wrote: > 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.
Like discussed offline, I captured the behavior of the default allocator here and added a note about no guarantee that custom allocators interpret this information. - Benjamin ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/69818/#review212401 ----------------------------------------------------------- On Feb. 4, 2019, 12:14 p.m., Benjamin Bannier wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/69818/ > ----------------------------------------------------------- > > (Updated Feb. 4, 2019, 12:14 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 is > interpreted by the default, hierarchical allocator for filtering out > resources not relevant to the framework, and for overriding any globally > configured `min_allocatable_resources` on a per framework, per role > basis. > > 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 > src/master/framework.cpp 4089cf4dfc65ac4dc5a092c04f4c2022ed8a1587 > > > Diff: https://reviews.apache.org/r/69818/diff/7/ > > > Testing > ------- > > `make check` > > > Thanks, > > Benjamin Bannier > >
