If Chronos is in fact further below its fair share at any given point in
time, then it will always get the offer. If, however, Chronos recently
declined that offer and we're still within its refuse_interval, then it
will have to be offered to the next framework (Marathon). In the scenario
where
Thanks, Adam, for explaining the fair share scheduling algorithm in more
detail. What is interesting is bumping up Chronos' refuse interval to 1s
didn't work. It only worked when it was bumped up to 5s (even with
Marathon). Is there any explanation for that? I would think that with the 1
second
Hi All,
Is there a with which in mesos we can monitor the scheduled tasks and their
resource access pattern and reschedule the tasks on the optimized
resources? For example like NUMA balancer in case of Linux on a NUMA system.
Regards,
Pradeep
As discussed in the last community meeting, we'd like to bump the minimum
required compiler version from GCC 4.4 to GCC 4.8.
The overall goals are to make Mesos development safer, faster, and reduce
the maintenance burden. Currently a lot of stout has different codepaths
for Pre-C++11 and
If you can run the pre/post steps in a container then I'd recommend
building a Docker image that includes your pre/post step scripting + your
algorithm and launching it using the built-in mesos Docker containerizer.
It's much simpler than managing the lifetime of the Docker container
yourself.
On
5 matches
Mail list logo
