aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From meghdoo...@yahoo.com.INVALID
Subject Re: Using a config file to support custom executors: potential paradigm shift
Date Thu, 09 Jul 2015 04:10:50 GMT
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
View raw message