question about cassandra.in.sh

[Koert Kuipers <ko...@tresata.com>]

i have an existing cassandra instance on my machine, it came with brisk and
lives in /usr/share/brisk/cassandra. it also created /usr/share/cassandra/
cassandra.in.sh

now i wanted to run another instance of cassandra (i needed a 0.7 version
for compatibility reasons), so i downloaded it from apache cassandra website
and installed it in /usr/share/cassandra-0.7

my problem is that the scripts for my cassandra 0.7 instance don't work
properly. the problem lies in the code snippets below. when i run the
scripts they source /usr/share/cassandra/cassandra.in.sh, which has the
wrong settings (it now loads all the jars from
/usr/share/brisk/cassandra/lib). i know i can fix it by settings
CASSANDRA_INCLUDE but i think thats not a very nice solution.

why was the decision made that the central "casssandra.in.sh" should have
higher priority than the local one? doesn't that break local installs?
wouldnt it make more sense if scripts assumed they were in SOMEDIR/bin and
then tried to load casssandra.in.sh from SOMEDIR first with the highest
priority?

best, koert


code snippet:
if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
    # Locations (in order) to use when searching for an include file.
    for include in /usr/share/cassandra/cassandra.in.sh \
                   /usr/local/share/cassandra/cassandra.in.sh \
                   /opt/cassandra/cassandra.in.sh \
                   ~/.cassandra.in.sh \
                   `dirname $0`/cassandra.in.sh; do
        if [ -r $include ]; then
            . $include
            break
        fi
    done

Re: question about cassandra.in.sh

[Eric Evans <ee...@acunu.com>]

On Thu, Aug 25, 2011 at 10:13 AM, Koert Kuipers <ko...@tresata.com> wrote:
> hey eric, the one thing i do not agree that it is the element of least
> surprise. i would argue that the default behavior for *nix appplications is
> that they find out what their home directory is and operate relative to
> that. something like:

I'm not sure what you mean by "home directory" here, but *nix
applications tend to have binaries installed to path, library
locations resolved, and other resource locations fixed at
compile-time.  But Java apps seldom adhere to platform conventions
anyway.

cassandra.in.sh is meant (was originally meant) to be site config,
providing the means to customize the install.  The one checked in to
bin/ is simply a default, and is (hopefully )setup with what will work
for most people, most of the time.

I guess least surprising might depend on who you ask, but for what
it's worth, the search order has been like that all along and this is
the first time that I'm aware of it coming up.

> script_dir="$(dirname "$(readlink -f ${BASH_SOURCE[0]})")"
> home_dir=${script_dir%/bin}
>
> or production quality code from hadoop-config.sh which is sourced by the
> main hadoop script:
> this="${BASH_SOURCE-$0}"
> bin=$(cd -P -- "$(dirname -- "$this")" && pwd -P)
> script="$(basename -- "$this")"
> this="$bin/$script"
> # the root of the Hadoop installation
> if [ -z "$HADOOP_HOME" ]; then
>   export HADOOP_HOME=`dirname "$this"`/..
> fi
>
> i find setting a variable in your shell like CASSANDRA_INCLUDE to be error
> prone. at some point i will forget what i set it to and them i am by
> accident using the wrong application. once applications are aware of their
> home dir all i have to do is "ln -s /usr/lib/cassandra-0.7/bin/nodetool
> /usr/sbin/nodetool-0.7" and then i can use it without risk of confusion.

Having multiple independent versions, one or more of which are
"installed" to the usual site-wide locations is not at all common that
I can see.  I'd also classify it as falling squarely in the Better
Know What You're Doing category.  Seen that way, editing
cassandra.in.sh, or passing an alternate using CASSANDRA_INCLUDE
doesn't seem unreasonable, but YMMV.

Your welcome to open a ticket though.

--
Eric Evans
Acunu | http://www.acunu.com | @acunu

Re: question about cassandra.in.sh

[Koert Kuipers <ko...@tresata.com>]

hey eric, the one thing i do not agree that it is the element of least
surprise. i would argue that the default behavior for *nix appplications is
that they find out what their home directory is and operate relative to
that. something like:

script_dir="$(dirname "$(readlink -f ${BASH_SOURCE[0]})")"
home_dir=${script_dir%/bin}

or production quality code from hadoop-config.sh which is sourced by the
main hadoop script:
this="${BASH_SOURCE-$0}"
bin=$(cd -P -- "$(dirname -- "$this")" && pwd -P)
script="$(basename -- "$this")"
this="$bin/$script"
# the root of the Hadoop installation
if [ -z "$HADOOP_HOME" ]; then
  export HADOOP_HOME=`dirname "$this"`/..
fi

i find setting a variable in your shell like CASSANDRA_INCLUDE to be error
prone. at some point i will forget what i set it to and them i am by
accident using the wrong application. once applications are aware of their
home dir all i have to do is "ln -s /usr/lib/cassandra-0.7/bin/nodetool
/usr/sbin/nodetool-0.7" and then i can use it without risk of confusion.

best, koert

On Wed, Aug 24, 2011 at 9:48 PM, Eric Evans <ee...@acunu.com> wrote:

> On Wed, Aug 24, 2011 at 1:28 PM, Koert Kuipers <ko...@tresata.com> wrote:
> > my problem is that the scripts for my cassandra 0.7 instance don't work
> > properly. the problem lies in the code snippets below. when i run the
> > scripts they source /usr/share/cassandra/cassandra.in.sh, which has the
> > wrong settings (it now loads all the jars from
> > /usr/share/brisk/cassandra/lib). i know i can fix it by settings
> > CASSANDRA_INCLUDE but i think thats not a very nice solution.
> >
> > why was the decision made that the central "casssandra.in.sh" should
> have
> > higher priority than the local one? doesn't that break local installs?
>
> It was considered the element of least surprise.  If it exists in
> /usr/share/cassandra then Cassandra's been "installed", and in the
> absence of any other data, that's probably what should be used.  If
> it's a local copy *and* there's a copy installed in
> /usr/share/cassandra, it's probably the owner of the local copy that
> needs to know what they are doing and intervene with
> CASSANDRA_INCLUDE.
>
> > wouldnt it make more sense if scripts assumed they were in SOMEDIR/bin
> and
> > then tried to load casssandra.in.sh from SOMEDIR first with the highest
> > priority?
>
> I don't think so, but then I was the one that reasoned out the current
> search order, so YMMV. :)
>
> > code snippet:
> > if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
> >     # Locations (in order) to use when searching for an include file.
> >     for include in /usr/share/cassandra/cassandra.in.sh \
> >                    /usr/local/share/cassandra/cassandra.in.sh \
> >                    /opt/cassandra/cassandra.in.sh \
> >                    ~/.cassandra.in.sh \
> >                    `dirname $0`/cassandra.in.sh; do
> >         if [ -r $include ]; then
> >             . $include
> >             break
> >         fi
> >     done
> >
>
> --
> Eric Evans
> Acunu | http://www.acunu.com | @acunu
>

Re: question about cassandra.in.sh

[Eric Evans <ee...@acunu.com>]

On Wed, Aug 24, 2011 at 1:28 PM, Koert Kuipers <ko...@tresata.com> wrote:
> my problem is that the scripts for my cassandra 0.7 instance don't work
> properly. the problem lies in the code snippets below. when i run the
> scripts they source /usr/share/cassandra/cassandra.in.sh, which has the
> wrong settings (it now loads all the jars from
> /usr/share/brisk/cassandra/lib). i know i can fix it by settings
> CASSANDRA_INCLUDE but i think thats not a very nice solution.
>
> why was the decision made that the central "casssandra.in.sh" should have
> higher priority than the local one? doesn't that break local installs?

It was considered the element of least surprise.  If it exists in
/usr/share/cassandra then Cassandra's been "installed", and in the
absence of any other data, that's probably what should be used.  If
it's a local copy *and* there's a copy installed in
/usr/share/cassandra, it's probably the owner of the local copy that
needs to know what they are doing and intervene with
CASSANDRA_INCLUDE.

> wouldnt it make more sense if scripts assumed they were in SOMEDIR/bin and
> then tried to load casssandra.in.sh from SOMEDIR first with the highest
> priority?

I don't think so, but then I was the one that reasoned out the current
search order, so YMMV. :)

> code snippet:
> if [ "x$CASSANDRA_INCLUDE" = "x" ]; then
>     # Locations (in order) to use when searching for an include file.
>     for include in /usr/share/cassandra/cassandra.in.sh \
>                    /usr/local/share/cassandra/cassandra.in.sh \
>                    /opt/cassandra/cassandra.in.sh \
>                    ~/.cassandra.in.sh \
>                    `dirname $0`/cassandra.in.sh; do
>         if [ -r $include ]; then
>             . $include
>             break
>         fi
>     done
>

-- 
Eric Evans
Acunu | http://www.acunu.com | @acunu