Hey Ben Thanks for clarifying it.
After reading mesos code today and experimenting with JenkinsSchedular of mesos-plugin, we figured that filter might not have any issue, they work just fine. The confusion was created because, mesos-plugin only specify a Refuse filter during launchTasks (1 sec), and not declineOffer (so a default of 5 sec is assumed). And, it wasn’t very clear from mesos-master logs which value of refuse_seconds is getting picked up. After, I modified declineOffer to also provide a refuseFilter, I was able to override value of refuse_seconds. And, then it was all good. Mohit On March 11, 2014 at 9:01:16 PM, Benjamin Hindman ([email protected]) wrote: Hey Mohit, Filters let you short-circuit declining offers by telling the allocator to not bother sending them. It looks like we might have a bug with filters. I've filed: https://issues.apache.org/jira/browse/MESOS-1085. Thanks for reporting. This might be a trivial fix if you'd like to check it out. Ben. On Mon, Mar 10, 2014 at 7:11 PM, Mohit Soni <[email protected]> wrote: > I would like to understand how LaunchTaskMessage's Filters work ? What's > the intent behind it ? I read the documentation, but got confused with > "Time to consider unused resources refused". Does that mean that for any > resource allocation chunk there can be three possible states: [used, > unused, refused] ? Also, how does allocator takes it into account. > > Another thing that I noticed was the value of refused seconds set as part > of LaunchTaskMessage is somehow not getting honored. For example: > https://github.com/jenkinsci/mesos-plugin/blob/master/src/main/java/org/jenkinsci/plugins/mesos/JenkinsScheduler.java#L324, > > sets the refuse seconds value to 1, but in mesos master logs, I see > following: > > I0310 18:28:25.381296 1153 hierarchical_allocator_process.hpp:590] > Framework 201403032301-1255541002-5050-1126-0364 filtered slave > 201403032301-1255541002-5050-1126-11 for 5secs > > Basically, it's using the default value. > -- > Mohit
