Mailing-List: contact issues-help@aurora.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.apache.org
Date: Wed, 13 Jan 2016 18:59:39 +0000 (UTC)
From: "Brian Hatfield (JIRA)" <jira@apache.org>
To: issues@aurora.apache.org
Message-ID: <JIRA.12929913.1452711551000.101172.1452711579875@Atlassian.JIRA>
In-Reply-To: <JIRA.12929913.1452711551000@Atlassian.JIRA>
References: <JIRA.12929913.1452711551000@Atlassian.JIRA>
 <JIRA.12929913.1452711551389@arcas>
Subject: [jira] [Created] (AURORA-1579) Allow preflight-check of Job
 schedulability.
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit

Brian Hatfield created AURORA-1579:
--------------------------------------

             Summary: Allow preflight-check of Job schedulability.
                 Key: AURORA-1579
                 URL: https://issues.apache.org/jira/browse/AURORA-1579
             Project: Aurora
          Issue Type: Task
          Components: Client, Scheduler
            Reporter: Brian Hatfield
            Priority: Minor


The goal of this feature is to allow users to check if their job (as configured) would likely be schedulable given Aurora's current offers. An extended form of this feature would be able to perform this test while assuming any current instance of the job in question would be stopped.

Here is the suggestion I sent to the mailing list describing my use-case for such a feature:
{quote}
We currently run a (relatively) small Mesos/Aurora cluster, and don't always have significant resource overhead available.

Sometimes, we go to schedule a job and we're just short of what we estimated-by-hand we'd need in the cluster for it. Most of the tasks schedule - but a few stay "PENDING" because of the resource constraint. This often confuses users, or in some cases, causes the command to block for a while until it eventually times out.

We're currently working in-house on automating somewhat-more-precise basic estimation with information sourced from /offers to get a sense of "nope, your task won't schedule" to provide fast feedback that doesn't manipulate the state of the cluster. 

However, our basic estimation doesn't include co-scheduling constraints, quotas, etc., which seem like something Aurora would be able to determine.
{quote}


--
This message was sent by Atlassian JIRA
(v6.3.4#6332)