On Wed, May 02, 2012 at 09:26AM, Owen O'Malley wrote: > On Tue, May 1, 2012 at 5:06 PM, Roman Shaposhnik <[email protected]> wrote: > > Personally, I'm concerned because of the following: > > # this will actually increase confusion somewhat among the folks > > who have used prior releases of Bigtop > > If you smooth off the rough edges of Bigtop, you'll get a lot more > adoption. In particular, none of the Apache projects have used a > pattern like that. If you look at the upstream projects like Hadoop, > Pig, or Zookeeper rpms they all use /etc/hadoop.
I don't see how the adoption can be increased by changing of the value of an env. var. ;) RPMs produced by different project might have different structure - this is really up to the maintainer. I personally think /etc/<prod>/<more stuff> is a way cleaner structure, because otherwise you'll end up mixing things in the same folder if later on non-config related files will need to end up in /etc/hadoop. No, I don't see how it makes sense. Cos > > # whatever we do has to be consistent through Bigtop which > > means changing all the /etc/<component>/conf locations as well. > > Agreed. > > > That will be quite a bit of work as far as validation is concerned. > > Wouldn't the smoke tests be sufficient? Clearly none of the upstream > projects has any dependency of the string /etc/$tool/conf. > > > AFAIK, if you deploy Hadoop from > > tarballs it doesn't actually assume anything in /etc, since it bundles > > all of the configs under the installation tree. > > This wouldn't change tarball deploys at all, naturally, since they > don't have any natural config directory except for following a link > from $tool/conf. > > -- Owen
