[ 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