The issue I face occurs under the following circumstance: The allocator initially provides five offers, out of which my framework, picks one and executes a task. The allocator then, begins to provide the offer that was selected previously by the framework. Is there any way to force the allocator to offer the same resources for every request?
On 31 May 2016 at 14:19, <[email protected]> wrote: > Replacing the allocator is possible but probably not the best path > forward. It's a big task to write your own. The requests are only meant to > be hints for the allocator anyway. Is offer latency a bottleneck for you? > With static or dynamic reservations you can earmark slabs of resources for > various framework roles ( > http://mesos.apache.org/documentation/latest/reservation/). You might > also try tuning the master knobs --allocation_interval and > --offer-timeout to mitigate against frameworks that hoard offers (e.g. > inconsiderate or buggy schedulers). > > On May 31, 2016, at 01:31, Nihal Harish <[email protected]> wrote: > > So the best approach would be to write my own hierarchical allocator? As > of now, I am currently filtering out offers made, but this adds latency > because, the required resources may not be offered for every request. > > On 31 May 2016 at 13:34, <[email protected]> wrote: > >> Just FYI, note the default hierarchical allocator doesn't do anything >> with the resource requests it receives. See >> https://github.com/apache/mesos/blob/master/src/master/allocator/mesos/hierarchical.cpp >> >> On May 30, 2016, at 23:58, Guangya Liu <[email protected]> wrote: >> >> I think that you can filter the offers based on slave attribute, all of >> the offers are assigned agent attributes in the offer: >> https://github.com/apache/mesos/blob/master/src/master/master.cpp#L5637 >> >> On Tue, May 31, 2016 at 2:33 PM, Nihal Harish <[email protected]> >> wrote: >> >>> Hi, >>> >>> The mesos.proto file allows us to specify request offers based on only >>> slave_id and resources, is there some way to request offers based on slave >>> attributes and/or hostname? >>> >>> Thanks. >>> Regards, >>> Nihal >>> >>> >> >
