Let me give you a concrete example for when and why this situation would occur. 1. Your framework gets an offer of 4 cpus from a single node (with 8 cpus). 2. You launch a task using 1 cpu, implicitly declining the remaining 3 cpus in the offer. 3. Another framework's task on the same node exits, and now its 2 cpus are offered to your framework. 4. After a default delay of 5 seconds, the previously implicitly declined 3 cpus will be reoffered (with a new offerId). 5. Your task completes/fails/exits, and its 1 cpu is offered back to your framework. Steps 3-5 could happen in any order, any number of times. Note that you can combine resources from multiple offers to launch one or more tasks. Even if your framework does not accept/decline/use its original offer, if more resources become available, and Mesos deems that they belong in your framework's fair share, they will be offered to you, even if you are hoarding other resources. There is an optional mesos-master --offer_timeout, after which the offer you are hoarding will be rescinded, and its resources offered to other frameworks.
On Sat, May 2, 2015 at 1:15 PM, Dario Rexin <[email protected]> wrote: > Yes, that's the default behaviour, but a framework can also set a filter > if it doesn't want resources from that slave until the current task > terminates. > > > > On 02.05.2015, at 21:29, Kannan Rajah <[email protected]> wrote: > > When a framework is registered, is it possible to get multiple offers from > same slave in succession? As in, if the framework accepted an offer from a > slave, will it get one more before releasing the first one? From some user > discussions, this seems to be the case. So I want to confirm it. > > -- > Kannan > >
