> On Jul 17, 2015, at 2:03 PM, Vinod Kone <[email protected]> wrote: > > I will be happy to shepherd this. Have you looked at MESOS-3037 > <https://issues.apache.org/jira/browse/MESOS-3037> that was filed recently > for essentially the same thing? We can add filters to that call too.
I saw that once you linked it. As long as the scheduler can call SUPPRESS explicitly I think it would work for us. IN don't see any details on SUPPRESS in the design doc? > Do you want this in the current API (scheduler driver) or can you wait > until the HTTP API comes out (ETA mid August)? I don't know when we plan to move to the HTTP API, but I suspect we would not be early adopters. Is the native Java API going away? If not, then it would be helpful for SUPPRESS to be available there. > If you can't wait, wait for > me to land MESOS-3037 and add the suppressOffers() driver call. We are running a hack where we suppress in the allocator if we receive a filter for INT32_MAX seconds. It's working well enough and will tide us over until the > Btw, we are calling this "suppress" instead of "quiesce". If you've a > better name, feel free to suggest. Now that I think about it, maybe > "FILTER" call and "filterOffers()" message are better? Do you mean passing a Filter object? We considered that, but didn't want to couple the fate of this message to the LaunchTasks message. The simpler optional seconds was sufficient (we always suppress indefinitely). The SUPPRESS is simple and cheap to evaluate; I'm not sure whether FILTER would be. If you can end up with a lot of filters or if filters are expensive to evaluate then we would end up having the same problems as DECLINE. > > On Fri, Jul 17, 2015 at 10:30 AM, James Peach <[email protected]> wrote: > >> Hi all, >> >> In our Mesos deployment, we end up with a lot of small frameworks (> 200) >> that hit their targets and have to refuse a lot of unwanted resources. This >> causes significant performance degradation and unnecessary memory use in >> the hierarchical allocator. >> >> I'm proposing a new QuiesceOffers message that a framework can use to >> suppress offers of unwanted resources. See MESOS-3075. This has basically >> the same semantics as refusing resources with a filter, except that is it >> explicit that the framework doesn't need any more resources. >> >> In addition to comments on the API, I'd also like to solicit a shepherd to >> get this change committed :) >> >> thanks, >> James
