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 <rdelv...@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 >
