[jira] [Reopened] (CASSANDRA-2356) make the debian package never start by default

["Sylvain Lebresne (JIRA)" <ji...@apache.org>]

     [ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]

Sylvain Lebresne reopened CASSANDRA-2356:
-----------------------------------------


I'm going to reopen this because there seems to be a pain to fix here ("restarting after upgrade is not the most friendly") and reading what's above, it seems the ticket has only been closed because CASSANDRA-2703 was supposed to supersede it, but CASSANDRA-2703 has also be closed to "later" for lack of motivation (and while I'm not against a debconf solution on principle, it sound more complicated and no-one seems to have interested in implementing/maintaining it).

Now I'm not sure what's the best solution here. But if it's simple to disable auto-restart during upgrade (and only then) with a simple message to indicate the service needs to be started manually, this would seems like a good enough solution to me.
                
> make the debian package never start by default
> ----------------------------------------------
>
>                 Key: CASSANDRA-2356
>                 URL: https://issues.apache.org/jira/browse/CASSANDRA-2356
>             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 start.
> 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 into:
> * 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.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira