bigtop-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Matt Foley <>
Subject Re: Guarding against the use of upstream scripts
Date Wed, 02 May 2012 18:44:44 GMT
What is the justification for saying "what we are doing in BigTop", when it
is diverging from what has been done for years in the Components?  It seems
that this is carelessly discarding what is being practiced at a lot of
sites, because you'd rather do it this way.  Generally speaking, we make
the Hadoop Ecosystem easier to use by adhering to familiar usage, rather
than diverging.  Please give reasons for the divergence.


On Wed, May 2, 2012 at 11:31 AM, Roman Shaposhnik <> wrote:

> On Wed, May 2, 2012 at 11:01 AM, Owen O'Malley <> wrote:
> > On Wed, May 2, 2012 at 8:34 AM, Roman Shaposhnik <> wrote:
> >> Guys,
> >>
> >> I've noticed lately that new users of the Bigtop distro fall prey
> >> to thinking that they can simply utilized upstream launcher scripts
> >> as is by running them from under /usr/lib/<component>bin
> >> directories. Something this works. More often it doesn't.
> >
> > This will break users in two ways:
> Just to be clear (and sorry for not being specific in the original email):
> this
> only applies to trunk e.g. Hadoop 2.X based Bigtop.
> > 1. Many user scripts use $HADOOP_HOME/bin/X to find script X.
> Not sure I understand how this applies to Hadoop 2.X codeline.
> HADOOP_HOME has been deprecated there and in fact now
> that we have split the sub-projects it no longer makes even a
> backward-compatibility sense to maintain the illusion.
> > 2. Until those scripts are available in other locations, there is no
> > choice. For users that want to manage the servers manually, having
> > access to the is required. Of course, it should be in
> > /usr/sbin/, but until it is of course the users needs
> > to reference it in $HADOOP_HOME/sbin/
> Right, but the Bigtop layout is completely different anyway. It has
> very little to do with the upstream Hadoop 2.X layout.
> Please consider this in the context of what we are doing in Bigtop,
> not what happens with upstream Hadoop.
> Thanks,
> Roman.

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