cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Brandon Williams (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2356) make the debian package never start by default
Date Tue, 24 May 2011 16:19:47 GMT


Brandon Williams commented on CASSANDRA-2356:

I posit that this could be solved by not making this mistake:

have chef/puppet install cassandra, do some configuration, then do the service start

A seasoned sysadmin wouldn't do this.  Their process would be more like:

* pull the configs from the VCS
* install the package

Adding a third step of starting the process is no big deal, and if you find that is better
I am for it, but I make this point because it sounds like you have chef/puppet editing files,
rather than keeping them under version control and pulling the entire thing over.  This isn't
good, because now figuring out what the history of your configs was is much more complex,
not to mention an extra class of bugs due to dealing with code, instead of version-controlled
plain text.

However, as I said I'm not against turning it off since the power user won't care about it
either way, and perhaps the new user will find it more friendly.  I think the redhat init
already capitulated here, so this brings us closer to package parity.

> make the debian package never start by default
> ----------------------------------------------
>                 Key: CASSANDRA-2356
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Packaging
>            Reporter: Jeremy Hanna
>            Assignee: Brandon Williams
>            Priority: Minor
>              Labels: debian, packaging
>             Fix For: 0.8.0
> Currently the debian package that installs cassandra starts cassandra by default.  It
sounds like that is a standard debian packaging convention.  However, if you want to bootstrap
a new node and want to configure it before it creates any sort of state information, it's
a pain.  I would think that the common use case would be to have it install all of the init
scripts and such but *not* have it start up by default.  That way an admin can configure cassandra
with seed, token, host, etc. information and then start it.  That makes it easier to programmatically
do this as well - have chef/puppet install cassandra, do some configuration, then do the service
> With the current setup, it sounds like cassandra creates state on startup that has to
be cleaned before a new configuration can take effect.  So the process of installing turns
> * install debian package
> * shutdown cassandra
> * clean out state (data/log dirs)
> * configure cassandra
> * start cassandra
> That seems suboptimal for the default case, especially when trying to automate new nodes
being bootstrapped.
> Another case might be when a downed node comes back up and starts by default and tries
to claim a token that has already been claimed by another newly bootstrapped node.  Rob is
more familiar with that case so I'll let him explain it in the comments.

This message is automatically generated by JIRA.
For more information on JIRA, see:

View raw message