aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Zameer Manji <zma...@apache.org>
Subject Re: Meaning and usage of job environments
Date Wed, 02 Sep 2015 21:42:38 GMT
+1 to moving the validation to the scheduler. I think a reasonable step
forward would be to set the defaults on the scheduler to be the same as
they are in the client and remove the code in the client.

On Wed, Sep 2, 2015 at 2:07 PM, Bill Farner <terasurfer@gmail.com> wrote:

> 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
>



-- 
Zameer Manji

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message