cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Duncan Sands (JIRA)" <>
Subject [jira] [Commented] (CASSANDRA-2356) make the debian package never start by default
Date Wed, 05 Mar 2014 08:28:49 GMT


Duncan Sands commented on CASSANDRA-2356:

Many Debian packages use the /etc/default/cassandra scheme suggested by Brandon Williams.
 Simple, standard - sounds good to me!  I don't understand why it was rejected.  For new installs
it should clearly contain ENABLED=false; for people upgrading, the upgrade script would have
to create this file if it didn't exist already with ENABLED=true, to preserve the previous

Another point that came up on IRC is that shutting down a C* instance using the init scripts
doesn't first drain the node.  As a result you get to replay all the commit logs when you
start it up again - this can take a long time.  So draining the node before shutdown (including
restart) can be a big win.

> make the debian package never start by default
> ----------------------------------------------
>                 Key: CASSANDRA-2356
>                 URL:
>             Project: Cassandra
>          Issue Type: Improvement
>          Components: Packaging
>            Reporter: Jeremy Hanna
>            Priority: Minor
>              Labels: debian, packaging
>         Attachments: 2356.txt
> 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 was sent by Atlassian JIRA

View raw message