Mailing-List: contact cassandra-commits-help@incubator.apache.org;
 run by ezmlm
Precedence: bulk
Reply-To: cassandra-dev@incubator.apache.org
Message-ID: <504098166.185501268251467225.JavaMail.jira@brutus.apache.org>
Date: Wed, 10 Mar 2010 20:04:27 +0000 (UTC)
From: "Jonathan Ellis (JIRA)" <jira@apache.org>
To: cassandra-commits@incubator.apache.org
Subject: [jira] Updated: (CASSANDRA-769) refuse to start node if ClusterName
 in storage-conf.xml is different from ClusterName in system
In-Reply-To: <1501865326.78681265401828147.JavaMail.jira@brutus.apache.org>
MIME-Version: 1.0
Content-Type: text/plain; charset=utf-8
Content-Transfer-Encoding: 7bit


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