Mailing-List: contact dev-help@aurora.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@aurora.apache.org
MIME-Version: 1.0
In-Reply-To: <1441224385149.41386@blue-yonder.com>
References: <1441224385149.41386@blue-yonder.com>
Date: Wed, 2 Sep 2015 14:07:37 -0700
Message-ID: 
 <CAJx_70UAdZWrm6R=ud8TnBqU2g4LYbHAxiCoWcvqfORwzOsj2w@mail.gmail.com>
Subject: Re: Meaning and usage of job environments
From: Bill Farner <terasurfer@gmail.com>
To: dev@aurora.apache.org
Content-Type: multipart/alternative; boundary=20cf3030c0416d248e051eca0e4a

--20cf3030c0416d248e051eca0e4a
Content-Type: text/plain; charset=UTF-8

Environments were introduced as a first-class concept for namespacing.  In
theory, it's useful so you can have something like a 'test' namespace that
contains all the same jobs as the 'prod' namespace.  Prior to this, users
were namespacing within the job name, which was not so nice.  There have
also been discussions around implied policy with environment names, but
that has not materialized.

In general, would you be opposed to moving this validation to the
> scheduler, so that it can be configured cluster wide?
>

I've wanted to see this happen, an would be in favor.

This would enable us to introduce environment names which are closer to our
> domain and organization.  Or is this even somewhat covered in the upcoming
> job tier implementation?
>

It's not covered by tiers.  Tiers are loosely related to environments, but
the current plan is to keep them decoupled.  I would encourage you to
explore the scheduler-side enforcement.


On Wed, Sep 2, 2015 at 1:06 PM, Erb, Stephan <Stephan.Erb@blue-yonder.com>
wrote:

> Hi everyone,
>
> I have been wondering about the environment part of Aurora jobkeys (devel,
> test, staging, staging1, ...prod).
>
> I guess you made the environment a first class citizen in order to enforce
> some kind of standardization. How is this working out for you in practice?
>
> IIRC, the current set of supported environment names is enforced by the
> client. In general, would you be opposed to moving this validation to the
> scheduler, so that it can be configured cluster wide? This would enable us
> to introduce environment names which are closer to our domain and
> organization.  Or is this even somewhat covered in the upcoming job tier
> implementation?
>
> Thanks for your input,
> Stephan

--20cf3030c0416d248e051eca0e4a--