You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Jeremy Hanna (JIRA)" <ji...@apache.org> on 2011/03/18 18:34:29 UTC
[jira] Created: (CASSANDRA-2356) make the debian package never
start 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
Reporter: Jeremy Hanna
Priority: Minor
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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-2356:
----------------------------------------
Fix Version/s: (was: 0.8.0)
1.0
Assignee: paul cannon (was: Brandon Williams)
> 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: paul cannon
> Priority: Minor
> Labels: debian, packaging
> Fix For: 1.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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-2356:
----------------------------------------
Attachment: 2356.txt
Patch to disable startup when /etc/default/cassandra has ENABLED set to zero (default.)
Since this is configuration file upgraders won't be affected.
> 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: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "paul cannon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13291209#comment-13291209 ]
paul cannon commented on CASSANDRA-2356:
----------------------------------------
Robert, are you proposing not having the Cassandra service automatically start, even on boot? That seems like it would run counter to the interests of most users.
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "paul cannon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038759#comment-13038759 ]
paul cannon commented on CASSANDRA-2356:
----------------------------------------
this works, but it could cause minor headaches for upgraders- users upgrading from a lower version may suddenly find that their cassandra no longer automatically starts on boot, and users upgrading from this version to a higher one will be more likely to have to resolve config-file conflicts, since they will have modified a config file that's somewhat likely to have upstream changes over time.
how about "touch /etc/cassandra/enabled to enable automatic startup of Cassandra" ?
> 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: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038835#comment-13038835 ]
Jonathan Ellis commented on CASSANDRA-2356:
-------------------------------------------
can it start-on-boot just not start-after-install?
> 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: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Resolved] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis resolved CASSANDRA-2356.
---------------------------------------
Resolution: Won't Fix
Fix Version/s: (was: 1.0)
Assignee: (was: paul cannon)
Okay, resolving as wontfix but see CASSANDRA-2703 for the debconf approach.
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Eric Evans (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290933#comment-13290933 ]
Eric Evans commented on CASSANDRA-2356:
---------------------------------------
{quote}
1) node A has token X
2) node A dies and the OS crashes
3) node A is replaced by node B, also at token X (say by restoring a full snapshot)
4) node A is rebooted (say as part of RMA process)
5) cluster accepts node A as the rightful owner of token X, because it has a later generation number by virtue of having been more recently started
6) you have a two nodes which contain the same but desychronized dataset, at the same token, and no straightforward way to unify them
{quote}
The best way to deal with a situation like this is to make Cassandra do the Right Thing. Barring that, you could hack the init script to check for this condition and make startup a noop (or error), which would work even if someone had overridden the start policy.
For what it's worth, I remember running across code recently that I think would safeguard against this; Is this a failure scenario that you've tested against recent versions?
bq. Are there any circumstances where auto-starting, esp. on packaged install or upgrade, is actually desirable?
This is considered configuration, and with any configuration all you can do is provide a reasonable default, something that will work for most of the people, most of the time. Starting a service by default is generally considered The Way[*] on Debian systems, (and hence the least surprising choice for our Debian package).
[*] The oft stated reason being that if the user didn't want the service running, they wouldn't have installed it.
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-2356:
----------------------------------------
Reviewer: (was: eevans)
> 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: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-2356:
----------------------------------------
Reviewer: eevans
> 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: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038647#comment-13038647 ]
Brandon Williams commented on CASSANDRA-2356:
---------------------------------------------
I posit that this could be solved by not making this mistake:
{quote}
have chef/puppet install cassandra, do some configuration, then do the service start
{quote}
A seasoned sysadmin wouldn't do this. Their process would be more like:
* pull the configs from the VCS
* install the package
Adding a third step of starting the process is no big deal, and if you find that is better I am for it, but I make this point because it sounds like you have chef/puppet editing files, rather than keeping them under version control and pulling the entire thing over. This isn't good, because now figuring out what the history of your configs was is much more complex, not to mention an extra class of bugs due to dealing with code, instead of version-controlled plain text.
However, as I said I'm not against turning it off since the power user won't care about it either way, and perhaps the new user will find it more friendly. I think the redhat init already capitulated here, so this brings us closer to package parity.
> 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: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.0
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Tamar Fraenkel (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13501723#comment-13501723 ]
Tamar Fraenkel commented on CASSANDRA-2356:
-------------------------------------------
I would also like that fix. The auto restart is a pain after upgrading, since I need to merge my cassandra.yaml and cassander-env.sh, and don't want the node to restart on its own.
> 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
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038857#comment-13038857 ]
Jonathan Ellis commented on CASSANDRA-2356:
-------------------------------------------
(Since either change is 1.0 material IMO, might as well go straight to debconf.)
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Updated] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-2356:
--------------------------------------
Component/s: Packaging
Fix Version/s: 0.8.0
Assignee: Brandon Williams
> 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: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.0
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Robert Coli (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13290598#comment-13290598 ]
Robert Coli commented on CASSANDRA-2356:
----------------------------------------
(
though I know this ticket is resolved WONTFIX, I came across this ticket and saw jeromatron say :
" 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. "
I believe I was probably supposed to comment on this ticket in 2011 and didn't...
)
I think that configuring Cassandra to auto-start under any circumstances should be considered harmful, because of this case :
1) node A has token X
2) node A dies and the OS crashes
3) node A is replaced by node B, also at token X (say by restoring a full snapshot)
4) node A is rebooted (say as part of RMA process)
5) cluster accepts node A as the rightful owner of token X, because it has a later generation number by virtue of having been more recently started
6) you have a two nodes which contain the same but desychronized dataset, at the same token, and no straightforward way to unify them
Are there any circumstances where auto-starting, esp. on packaged install or upgrade, is actually desirable?
> 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: https://issues.apache.org/jira/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "paul cannon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038854#comment-13038854 ]
paul cannon commented on CASSANDRA-2356:
----------------------------------------
Oh I'm still fine with putting this in as a stopgap.
> 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: paul cannon
> Priority: Minor
> Labels: debian, packaging
> Fix For: 1.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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038853#comment-13038853 ]
Brandon Williams commented on CASSANDRA-2356:
---------------------------------------------
I think that's even more surprising behavior. After talking with Paul about it, we decided to make it automagical with debconf, but push this to 1.0
> 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: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038652#comment-13038652 ]
Jonathan Ellis commented on CASSANDRA-2356:
-------------------------------------------
Agreed that it doesn't matter for power user. For new user autostart is distinctly less friendly because of cluster name and other state. So +1 no autostart from 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
> Assignee: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.0
>
>
> 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.
For more information on JIRA, see: http://www.atlassian.com/software/jira
[jira] [Commented] (CASSANDRA-2356) make the debian package never
start by default
Posted by "paul cannon (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-2356?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13038849#comment-13038849 ]
paul cannon commented on CASSANDRA-2356:
----------------------------------------
Yes, and that's simpler to accomplish, it's just potentially bewildering for the small number of people who inadvertently reboot between installation and configuration.
> 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: Brandon Williams
> Priority: Minor
> Labels: debian, packaging
> Fix For: 0.8.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 is automatically generated by JIRA.
For more information on JIRA, see: http://www.atlassian.com/software/jira