There is no support for affinity-based scheduling today, but it has come up several times and i'm open to the idea.
Without great care, this type of constraint could become difficult to reason about and implement in a way that does not suffer from pathological cases. Today, scheduling is entirely with hard constraints (as opposed to preferences), and tasks are scheduled independently**. The upside is this allows us to ignore the NP-hard side of scheduling and create a relatively deterministic system. Consider a cluster with 2 AZs, where one AZ is nearly full (AZ-F), and one is empty (AZ-E). You schedule a 2-instance job requiring AZ affinity. The scheduler may select a resource in AZ-F for the first instance, defining a placement requirement for the second instance. However, AZ-F is now completely full, and the second instance cannot be scheduled. The obvious improvement is to consider all instances of the job when scheduling any of them, but the same pathological case exists. A question for you, to explore your use case - In the above scenario, which is preferable: 1) the scheduler gives up on affinity and places the 2nd instance in AZ-E, or 2.) the second instance remains in pending indefinitely The mantra of Aurora's design so far would favor (1), as we always err on the side of availability. This would effectively create a scheduling preference (rather than requirement), however. *** for the sake of user fencing, this is not entirely true. but for scheduling decisions it is* On Sun, Apr 3, 2016 at 8:52 PM, Brian Hatfield <[email protected]> wrote: > Hi, > > I am aware of constraints like 'host': 'limit:2', but I was wondering if > there was a constraint where I could say "I want everyone to have the same > X". > > My use-case is AWS: I want all of a job to only be scheduled within a > single availability zone, but I don't care which one - wherever the job can > be scheduled is fine. The specific purpose is to save on cross-az network > data transfer costs. > > The best workaround I can think of is manually specifying which AZ to > schedule a job in, but that has all sorts of drawbacks, mostly that it's > the scheduler's job to do this :-) > > Am I missing a nuance of the constraint system that would allow for this? > > Thank you! > Brian > > >
