@David, after receiving and declining offer for the first time, chronos's share is still the smaller one, so mesos continues to provide offer to chronos instead of marathon. @Elizabeth, I will try with the latest mesos a moment later.
2015年4月9日 上午8:37于 Elizabeth Lingg <[email protected]>写道： > > Correct, the issue we were seeing is that Chronos would decline the offer, > but Chronos would keep getting it back instead of it being offered to > Marathon. We were reproducing this issue on a cluster with a single > master/slave, which is a bit of an anti-pattern. I'm not sure if anyone was > able to reproduce this with the latest version of Mesos. > > -Elizabeth > > On Wed, Apr 8, 2015 at 5:19 PM, David Greenberg <[email protected]> > wrote: >> >> I believe that DRF is more of a "right of first refusal." Even though >> marathon's got the higher share, all that means is that chronos will get the >> offer first; marathon will have to wait until chronos declines it. >> >> On Wed, Apr 8, 2015 at 5:33 PM Elizabeth Lingg <[email protected]> >> wrote: >>> >>> Hi, >>> >>> This sounds like an issue we encountered, >>> https://issues.apache.org/jira/browse/MESOS-2546. Are you able to reproduce >>> this in the latest release? If so, could you add a comment to the issue? >>> >>> Thanks, >>> Elizabeth >>> >>> On Wed, Apr 8, 2015 at 3:35 AM, <[email protected]> wrote: >>>> >>>> Suppose I registered two frameworks namely marathon and chronos(both in >>>> role *) one after another, successfully deployed and run one app app1 by >>>> marathon, also deployed one cron app app2 by chronos, before app2 due or >>>> after app2 finished, I can't deploy and launch any new app by marathon >>>> although there are many resources left, because mesos will send offer to >>>> chronos all the time as share of chronos is smaller according to DRF, so >>>> is DRF unreasonable and is there any advice on how to allocate resources >>>> in this scenario? Any suggestipn will be appreciate. >>>> Best regards! >>> >>> >
