cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Jonathan Ellis (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CASSANDRA-769) refuse to start node if ClusterName in storage-conf.xml is different from ClusterName in system
Date Wed, 10 Mar 2010 20:04:27 GMT

     [ 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.


Mime
View raw message