+1 On Thu, Dec 8, 2016 at 1:36 PM, Jim Apple <[email protected]> wrote:
> I like this idea. > > On Thu, Dec 8, 2016 at 1:26 PM, Tim Armstrong <[email protected]> > wrote: > > Hi All, > > I wanted to float an idea to improve the usability of impala-config.sh > > > > One problem we've seen a lot is that certain config values, e.g. > > IMPALA_TOOLCHAIN_BUILD_ID can be overridden by preexisting environment > > variables. This is useful for testing against alternate components but > > leads to confusing errors if you re-source a changed impala-config.sh and > > get a mix of old and new config values. E.g. I've seen multiple people > run > > into confusing errors where it looks like files are missing from the > > toolchain s3 bucket. > > > > My idea is that we should remove this overriding mechanism and add an > > alternative one without the problem based on additional config files. > > impala-config.sh would determine the default values, which could be > > overridden by additional config values per-branch or in the local dev > > environment. > > > > My initial idea is to have: > > > > ./bin/impala-config.sh > > ./bin/impala-config-branch.sh > > ./bin/impala-config-local.sh > > > > impala-config-branch.sh would be blank by default and version-controlled, > > and could be used on release/development branches to override particular > > config values. This would make it simpler to merge and rebase branches. > > > > impala-config-local.sh would be non-existent by default and added to > > .gitignore. Users can then put whatever values they want for local > testing. > > > > Sourcing impala-config.sh would cause the config to be fully reset, > > avoiding any staleness issues. > > > > What do people think? > > > > - Tim >
