aurora-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bill Farner <>
Subject Re: Using a config file to support custom executors: potential paradigm shift
Date Thu, 02 Jul 2015 19:10:13 GMT
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

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?



On Wed, Jul 1, 2015 at 3:34 PM, Renan DelValle <>

> 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

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