[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14195068#comment-14195068 ]
Michael Shuler commented on CASSANDRA-2356: ------------------------------------------- [~sparkprime] with regards to node join messages, please open a new ticket for that request, including the actions you performed, the existing messages, and desired additions or changes. This ticket is only about not starting deb installs by default. :) > 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 > Assignee: Michael Shuler > Priority: Minor > Labels: debian, packaging > Fix For: 3.0 > > 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 was sent by Atlassian JIRA (v6.3.4#6332)