Use case:
- Fleet contains 4 cores and 8 cores machines.
- The task would prefer to use a 8 cores machine if possible.
- Under load, any VM will do.
Details:
- Similar in spirit to issue 143, the request dimension could either have
multiple values or one optional value. The main difference with 143 is that
each value has not the same weight, the task would prefer to wait several
seconds instead of being dispatched to the lesser interesting dimension value.
- It's akin issue 144 in the sense that it's a soft scheduling rule, which can
be overcome upon heavy load.
Implementation:
- Instead of having one TaskToRun entity as child of TaskRequest, have N
TaskToRun, each with the different dimension values *and* with a different
priority. Upon reaping, all TaskToRun are reaped simultaneously. Since it's all
under the same entity group and the entities are small by design, it's a fine
option.
- Add a "Minimum wait" value on the less interesting dimension values. It could
be implemented by making the task "more recent" than it actually is. In
practice this doesn't help since the low value bot could still be first to
query and reap it. The workaround is to add TaskToRun.minimum_wait_secs or
TaskToRun.not_valid_until_ts value. It's likely fine but we'll have to see
under load if it affects performance.
- The multiple dimensions could be set in the TaskToRun itself. It would
enlarge the TaskToRun but it's maybe fine. It needs to be tested for
performance.
Original issue reported on code.google.com by maruel@chromium.org on 27 Jan 2015 at 6:08
Original issue reported on code.google.com by
maruel@chromium.orgon 27 Jan 2015 at 6:08