aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chris Huegle <ch...@tellapart.com>
Subject Re: Using a config file to support custom executors: potential paradigm shift
Date Thu, 09 Jul 2015 06:50:14 GMT
One fact to consider is that if it's encoded blobs via switches, then the
user has control over the executor without special handling.

If it's server side config, admins have control.

I could see valid use cases for both, and even a combination of the two.

I would lean towards having the tech support layered/both, giving admins
the ability to choose which works best for their situation.
 On Jul 8, 2015 9:10 PM, <meghdoot_b@yahoo.com.invalid> wrote:

> In general the number of executors supported would be not very dynamic but
> as needed in that deployment environment. The config file listing all the
> supported executors can be simply put in the deb or rpm package of the
> scheduler for example.
>
> If values are fairly dynamic then the mesos approach makes sense. In the
> end even if passed command line where does that blob live? It will end up
> in systems like puppet or maybe some data store.
>
> Thx
>
> Sent from my iPhone
>
> > On Jul 8, 2015, at 5:56 PM, Jay Buffington <me@jaybuff.com> wrote:
> >
> > I'm a couple of days late to this party, but I wanted to chime in on
> this.
> >
> > Mesos has a couple of command line flags that take a json blob.
> > See --acls and --firewall-rules:
> > http://mesos.apache.org/documentation/latest/configuration/
> >
> > This technique makes a lot of sense to me.  Can we follow that convention
> > for
> > the custom executor stuff?
> >
> > Thanks,
> > Jay
> >
> >
> >> On Thu, Jul 2, 2015 at 12:10 PM, Bill Farner <wfarner@apache.org>
> wrote:
> >>
> >> Thanks for starting this discussion, Renan!
> >>
> >> I think it's clear that the feature you're adding calls for a
> configuration
> >> file.  I'm realizing now that we do have some precedent for
> configuration
> >> files with the recently-introduced security controls [1].  In that case
> the
> >> sane path was obvious since we pass the configuration file in an
> >> established format to third-party code (Apache Shiro).
> >>
> >> I see several paths ahead:
> >>
> >> 1.) start with individual feature-oriented configuration files and
> >> re-assess down the road
> >>
> >> 2.) establish a convention for a single global configuration file
> >>
> >> 3.) (2) and migrate command line arguments to a configuration file
> >>
> >> My personal preference is (1), so as to not force Renan to start a yak
> >> shave, and because i think willingness to change things down the road is
> >> important.
> >>
> >> I include (3) because people have inquired about that in the past.
> >>
> >> Does anyone have a preference which path we take?  Are there other
> options
> >> i'm not thinking about?
> >>
> >>
> >> [1]
> >>
> >>
> https://github.com/apache/aurora/blob/master/docs/security.md#http-spnego-authentication-kerberos
> >>
> >> -=Bill
> >>
> >> On Wed, Jul 1, 2015 at 3:34 PM, Renan DelValle <rdelval1@binghamton.edu
> >
> >> wrote:
> >>
> >>> Hi all,
> >>>
> >>> I'm currently working on bringing custom executor support to Aurora
> >>> (AURORA-1288). As development and discussions about the most adequate
> >>> solution to this problem have moved along, I've reached a crossroad
> >>> where I need the community's input on the implementation path this
> >>> feature will take.
> >>>
> >>> Right now, after evaluating other options,  it seems that the safest
> >>> and most flexible way to providing users the ability to configure
> >>> their own custom executor may be to use a configuration file.
> >>>
> >>> However, as there is no previous use of a config file (everything has
> >>> been done through command line up until now), a discussion is
> >>> necessary about this possible shift in paradigm due to the fact that,
> >>> if this route is taken, it will set a precedent for Aurora.
> >>>
> >>> As Bill Farner said in his comment on Jira, all in all, this is
> >>> discussion should be about how should approach this potential paradigm
> >>> shift.
> >>>
> >>> -Renan
> >>
>

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