aurora-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Zameer Manji (JIRA)" <>
Subject [jira] [Commented] (AURORA-184) Implicit scheduling constraints should be removed
Date Fri, 30 Jan 2015 19:27:35 GMT


Zameer Manji commented on AURORA-184:

Thanks to a patch from [~fpfeiffer] the implicit constraints for host and rack can be disabled.

commit db6a19994d7fc36b09aa1108d680f3418901d628
Author: Florian Pfeiffer <>
Date:   Fri Jan 30 11:24:37 2015 -0800

    [AURORA-184] Remove hardcoded 'host' and 'rack' limit constraints
    This is the first step for AURORA-184, that removes the default host&rack limit
    The second step that's still missing would be to add like
    "--default-constraints" as start parameter to the scheduler.
    AURORA-174 could probably be closed with this?(since the rack limit constraint
    can be configured in the .aurora file)
    I can't really estimate the effect of my changes in
    StorageBackfillTest&SchedulerThriftInterfaceTest, please have a closer look at
    the changes I did there.
    Since this is also my first code submit, comments about codestyle&other bad
    habbits are very appreciated.
    Testing Done:
    Added test for ConfigurationManager.hasName
    Added test testNoHostAndRackConstraintsAdded, that checks if the constraints are
    Tested on vagrant devcluster to see if constraints are also gone in "real life"
    Bugs closed: AURORA-184
    Reviewed at

 .../configuration/        | 58 ++++++++++++----------
 .../configuration/    | 29 +++++++++++
 2 files changed, 62 insertions(+), 25 deletions(-)

> Implicit scheduling constraints should be removed
> -------------------------------------------------
>                 Key: AURORA-184
>                 URL:
>             Project: Aurora
>          Issue Type: Story
>          Components: Scheduler
>            Reporter: Kevin Sweeney
>            Assignee: Florian Pfeiffer
> Right now the scheduler hardcodes "host" and "rack" limit constraints into submitted
jobs. These require slave attributes to be set on the slave command-line, which means deploying
aurora on a running mesos cluster needs a hard slave restart (changing slave attributes invalidates
recovery metadata, meaning underlying tasks must be killed). In addition, "host" and "rack"
might not accurately capture failure domains in other mesos deployments.
> Make this constraint-set configurable at deploy-time, defaulting to empty.

This message was sent by Atlassian JIRA

View raw message