You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@cassandra.apache.org by "Robert Coli (JIRA)" <ji...@apache.org> on 2010/02/05 21:30:28 UTC
[jira] Created: (CASSANDRA-769) refuse to start node if ClusterName
in storage-conf.xml is different from ClusterName in system
refuse to start node if ClusterName in storage-conf.xml is different from ClusterName in system
-----------------------------------------------------------------------------------------------
Key: CASSANDRA-769
URL: https://issues.apache.org/jira/browse/CASSANDRA-769
Project: Cassandra
Issue Type: New Feature
Components: Core
Reporter: Robert Coli
Priority: Minor
Summary :
When running multiple clusters and managing storage-conf.xml options via an external mechanism such as puppet, it is possible to induce unwanted behavior by giving a node a conf file containing a new ClusterName.
Behavior in current trunk :
1) Running node which is part of ClusterName "A" stops.
2) storage-conf.xml gets new ClusterName "B" (by accident, one presumes).
3) Node starts and tries to participate in ClusterName "B", but has a very hard time of it because it is configured to participate in cluster "A". "Bad things" happen.
Requested behavior :
1) Node from ClusterName "A" stops.
2) storage-conf.xml gets new ClusterName "B"
3) Node notices that the node already has configuration state for a different ClusterName and errors and refuses to start, preserving its current state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-769) refuse to start node if ClusterName
in storage-conf.xml is different from ClusterName in system
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-769:
---------------------------------------
Attachment: 0002_store_cluster_in_systable_and_exit_on_mismatch.txt
0001_warn_on_gossip_from_wrong_cluster.txt
Patch 01 to warn on cluster mismatch during gossip, which shouldn't happen with 02 to store the clustername in the system table and exit with an error on mismatch.
> refuse to start node if ClusterName in storage-conf.xml is different from ClusterName in system
> -----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-769
> URL: https://issues.apache.org/jira/browse/CASSANDRA-769
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Robert Coli
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.6
>
> Attachments: 0001_warn_on_gossip_from_wrong_cluster.txt, 0002_store_cluster_in_systable_and_exit_on_mismatch.txt
>
>
> Summary :
> When running multiple clusters and managing storage-conf.xml options via an external mechanism such as puppet, it is possible to induce unwanted behavior by giving a node a conf file containing a new ClusterName.
> Behavior in current trunk :
> 1) Running node which is part of ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B" (by accident, one presumes).
> 3) Node starts and tries to participate in ClusterName "B", but has a very hard time of it because it is configured to participate in cluster "A". "Bad things" happen.
> Requested behavior :
> 1) Node from ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B"
> 3) Node notices that the node already has configuration state for a different ClusterName and errors and refuses to start, preserving its current state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Assigned: (CASSANDRA-769) refuse to start node if
ClusterName in storage-conf.xml is different from ClusterName in system
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams reassigned CASSANDRA-769:
------------------------------------------
Assignee: Brandon Williams
> refuse to start node if ClusterName in storage-conf.xml is different from ClusterName in system
> -----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-769
> URL: https://issues.apache.org/jira/browse/CASSANDRA-769
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Robert Coli
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.6
>
>
> Summary :
> When running multiple clusters and managing storage-conf.xml options via an external mechanism such as puppet, it is possible to induce unwanted behavior by giving a node a conf file containing a new ClusterName.
> Behavior in current trunk :
> 1) Running node which is part of ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B" (by accident, one presumes).
> 3) Node starts and tries to participate in ClusterName "B", but has a very hard time of it because it is configured to participate in cluster "A". "Bad things" happen.
> Requested behavior :
> 1) Node from ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B"
> 3) Node notices that the node already has configuration state for a different ClusterName and errors and refuses to start, preserving its current state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-769) refuse to start node if ClusterName
in storage-conf.xml is different from ClusterName in system
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-769:
---------------------------------------
Attachment: 769.txt
Patch to issue warnings any time there is a clusterId mismatch during gossip.
> refuse to start node if ClusterName in storage-conf.xml is different from ClusterName in system
> -----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-769
> URL: https://issues.apache.org/jira/browse/CASSANDRA-769
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Robert Coli
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.6
>
> Attachments: 769.txt
>
>
> Summary :
> When running multiple clusters and managing storage-conf.xml options via an external mechanism such as puppet, it is possible to induce unwanted behavior by giving a node a conf file containing a new ClusterName.
> Behavior in current trunk :
> 1) Running node which is part of ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B" (by accident, one presumes).
> 3) Node starts and tries to participate in ClusterName "B", but has a very hard time of it because it is configured to participate in cluster "A". "Bad things" happen.
> Requested behavior :
> 1) Node from ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B"
> 3) Node notices that the node already has configuration state for a different ClusterName and errors and refuses to start, preserving its current state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-769) refuse to start node if ClusterName
in storage-conf.xml is different from ClusterName in system
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Brandon Williams updated CASSANDRA-769:
---------------------------------------
Attachment: (was: 769.txt)
> refuse to start node if ClusterName in storage-conf.xml is different from ClusterName in system
> -----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-769
> URL: https://issues.apache.org/jira/browse/CASSANDRA-769
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Robert Coli
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.6
>
>
> Summary :
> When running multiple clusters and managing storage-conf.xml options via an external mechanism such as puppet, it is possible to induce unwanted behavior by giving a node a conf file containing a new ClusterName.
> Behavior in current trunk :
> 1) Running node which is part of ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B" (by accident, one presumes).
> 3) Node starts and tries to participate in ClusterName "B", but has a very hard time of it because it is configured to participate in cluster "A". "Bad things" happen.
> Requested behavior :
> 1) Node from ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B"
> 3) Node notices that the node already has configuration state for a different ClusterName and errors and refuses to start, preserving its current state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Updated: (CASSANDRA-769) refuse to start node if ClusterName
in storage-conf.xml is different from ClusterName in system
Posted by "Jonathan Ellis (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-769?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Jonathan Ellis updated CASSANDRA-769:
-------------------------------------
Fix Version/s: 0.6
> refuse to start node if ClusterName in storage-conf.xml is different from ClusterName in system
> -----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-769
> URL: https://issues.apache.org/jira/browse/CASSANDRA-769
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Robert Coli
> Priority: Minor
> Fix For: 0.6
>
>
> Summary :
> When running multiple clusters and managing storage-conf.xml options via an external mechanism such as puppet, it is possible to induce unwanted behavior by giving a node a conf file containing a new ClusterName.
> Behavior in current trunk :
> 1) Running node which is part of ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B" (by accident, one presumes).
> 3) Node starts and tries to participate in ClusterName "B", but has a very hard time of it because it is configured to participate in cluster "A". "Bad things" happen.
> Requested behavior :
> 1) Node from ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B"
> 3) Node notices that the node already has configuration state for a different ClusterName and errors and refuses to start, preserving its current state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-769) refuse to start node if
ClusterName in storage-conf.xml is different from ClusterName in system
Posted by "Brandon Williams (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845472#action_12845472 ]
Brandon Williams commented on CASSANDRA-769:
--------------------------------------------
Since the ClusterName is not persisted in any place besides the storage-conf.xml, there's really no way to know this has been changed on startup.
> refuse to start node if ClusterName in storage-conf.xml is different from ClusterName in system
> -----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-769
> URL: https://issues.apache.org/jira/browse/CASSANDRA-769
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Robert Coli
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.6
>
> Attachments: 769.txt
>
>
> Summary :
> When running multiple clusters and managing storage-conf.xml options via an external mechanism such as puppet, it is possible to induce unwanted behavior by giving a node a conf file containing a new ClusterName.
> Behavior in current trunk :
> 1) Running node which is part of ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B" (by accident, one presumes).
> 3) Node starts and tries to participate in ClusterName "B", but has a very hard time of it because it is configured to participate in cluster "A". "Bad things" happen.
> Requested behavior :
> 1) Node from ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B"
> 3) Node notices that the node already has configuration state for a different ClusterName and errors and refuses to start, preserving its current state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
[jira] Commented: (CASSANDRA-769) refuse to start node if
ClusterName in storage-conf.xml is different from ClusterName in system
Posted by "Chris Goffinet (JIRA)" <ji...@apache.org>.
[ https://issues.apache.org/jira/browse/CASSANDRA-769?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12845481#action_12845481 ]
Chris Goffinet commented on CASSANDRA-769:
------------------------------------------
Brandon, I think we should be storing that meta data on disk as well. From an operations standpoint, issuing warnings is not good enough. You can really blow up clusters.
> refuse to start node if ClusterName in storage-conf.xml is different from ClusterName in system
> -----------------------------------------------------------------------------------------------
>
> Key: CASSANDRA-769
> URL: https://issues.apache.org/jira/browse/CASSANDRA-769
> Project: Cassandra
> Issue Type: New Feature
> Components: Core
> Reporter: Robert Coli
> Assignee: Brandon Williams
> Priority: Minor
> Fix For: 0.6
>
> Attachments: 769.txt
>
>
> Summary :
> When running multiple clusters and managing storage-conf.xml options via an external mechanism such as puppet, it is possible to induce unwanted behavior by giving a node a conf file containing a new ClusterName.
> Behavior in current trunk :
> 1) Running node which is part of ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B" (by accident, one presumes).
> 3) Node starts and tries to participate in ClusterName "B", but has a very hard time of it because it is configured to participate in cluster "A". "Bad things" happen.
> Requested behavior :
> 1) Node from ClusterName "A" stops.
> 2) storage-conf.xml gets new ClusterName "B"
> 3) Node notices that the node already has configuration state for a different ClusterName and errors and refuses to start, preserving its current state.
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.