[ 
https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13640892#comment-13640892
 ] 

Arthur Zubarev commented on CASSANDRA-2356:
-------------------------------------------

I would really like to control the restart aspect. Thing is I have an admin who 
is not Cassandra savvy she can update all the packages and then Cassanrda would 
restart w/o us even knowing and that will compromise the application 
availability.
                
> 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

Reply via email to