[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15037483#comment-15037483 ] Marcus Olsson commented on CASSANDRA-9474: -- Done! :) > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2-1.patch, CASSANDRA-9474-2.2.patch, > CASSANDRA-9474-3.0-1.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15036250#comment-15036250 ] Paulo Motta commented on CASSANDRA-9474: [~molsson] can you change the state to patch available? Then we can mark as ready to commit. It seems we missed the 2.1.12 and 2.2.4 release cuts, so this will only go into the next releases. > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2-1.patch, CASSANDRA-9474-2.2.patch, > CASSANDRA-9474-3.0-1.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034815#comment-15034815 ] Paulo Motta commented on CASSANDRA-9474: Tests look good (paired with main branch failures). Marking as ready to commit. > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2-1.patch, CASSANDRA-9474-2.2.patch, > CASSANDRA-9474-3.0-1.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034282#comment-15034282 ] Marcus Olsson commented on CASSANDRA-9474: -- Great! :) > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2-1.patch, CASSANDRA-9474-2.2.patch, > CASSANDRA-9474-3.0-1.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15034062#comment-15034062 ] Paulo Motta commented on CASSANDRA-9474: Thanks! Resubmitted tests, should be +1 if CI doesn't complain. ||2.1||2.2||3.0||3.1||trunk|| |[branch|https://github.com/apache/cassandra/compare/cassandra-2.1...pauloricardomg:2.1-9474]|[branch|https://github.com/apache/cassandra/compare/cassandra-2.2...pauloricardomg:2.2-9474-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.0...pauloricardomg:3.0-9474-v2]|[branch|https://github.com/apache/cassandra/compare/cassandra-3.1...pauloricardomg:3.1-9474-v2]|[branch|https://github.com/apache/cassandra/compare/trunk...pauloricardomg:trunk-9474-v2]| |[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-9474-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-9474-v2-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-9474-v2-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.1-9474-v2-testall/lastCompletedBuild/testReport/]|[testall|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-9474-v2-testall/lastCompletedBuild/testReport/]| |[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.1-9474-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-2.2-9474-v2-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.0-9474-v2-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-3.1-9474-v2-dtest/lastCompletedBuild/testReport/]|[dtest|http://cassci.datastax.com/view/Dev/view/paulomotta/job/pauloricardomg-trunk-9474-v2-dtest/lastCompletedBuild/testReport/]| > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2-1.patch, CASSANDRA-9474-2.2.patch, > CASSANDRA-9474-3.0-1.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033470#comment-15033470 ] Sam Tunnicliffe commented on CASSANDRA-9474: bq. This was missed as it was a complement to the original rack check which was based on 2.1 Cool, thanks. I was just curious in case there was some dependency on something in the startup sequence that happened after the startup checks had run. > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[
https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033463#comment-15033463
]
Paulo Motta commented on CASSANDRA-9474:
[~beobal] This was missed as it was a complement to the original rack check
which was based on 2.1 (which does not have {{StartupChecks}}) and was
initially implemented as part of {{SystemKeyspace.checkHealth()}}, and during
commit moved to {{CassandraDaemon}} but outside the {{StartupChecks}} so I
assumed it was in a correct place and didn't looked further (my bad). I agree
it's more appropriate/elegant for these checks to be on {{StartupChecks}}.
Thanks for the suggestion!
[~molsson] could you provide 2.2+ patches moving the check to {{StartupChecks}}
? The only nit is that it should go *after* the {{checkSystemKeyspaceState}}
check, since it depends on the system keyspace being loaded.
> Validate dc information on startup
> --
>
> Key: CASSANDRA-9474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9474
> Project: Cassandra
> Issue Type: Improvement
> Environment: Cassandra 2.1.5
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
> Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x
>
> Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch,
> CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch,
> cassandra-2.1-dc_rack_healthcheck.patch
>
>
> When using GossipingPropertyFileSnitch it is possible to change the data
> center and rack of a live node by changing the cassandra-rackdc.properties
> file. Should this really be possible? In the documentation at
> http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html
> it's stated that you should ??Choose the name carefully; renaming a data
> center is not possible??, but with this functionality it doesn't seem
> impossible(maybe a bit hard with changing replication etc.).
> This functionality was introduced by CASSANDRA-5897 so I'm guessing there is
> some use case for this?
> Personally I would want the DC/rack settings to be as restricted as the
> cluster name, otherwise if a node could just join another data center without
> removing it's local information couldn't it mess up the token ranges? And
> suddenly the old data center/rack would loose 1 replica of all the data that
> the node contains.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[
https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15033389#comment-15033389
]
Sam Tunnicliffe commented on CASSANDRA-9474:
Is there a particular reason why the dc and rack checks are not implemented as
{{StartupCheck}} instances and run as part of the {{StartupChecks::verify}} in
{{CassandraDaemon::setup}}?
> Validate dc information on startup
> --
>
> Key: CASSANDRA-9474
> URL: https://issues.apache.org/jira/browse/CASSANDRA-9474
> Project: Cassandra
> Issue Type: Improvement
> Environment: Cassandra 2.1.5
>Reporter: Marcus Olsson
>Assignee: Marcus Olsson
> Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x
>
> Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch,
> CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch,
> cassandra-2.1-dc_rack_healthcheck.patch
>
>
> When using GossipingPropertyFileSnitch it is possible to change the data
> center and rack of a live node by changing the cassandra-rackdc.properties
> file. Should this really be possible? In the documentation at
> http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html
> it's stated that you should ??Choose the name carefully; renaming a data
> center is not possible??, but with this functionality it doesn't seem
> impossible(maybe a bit hard with changing replication etc.).
> This functionality was introduced by CASSANDRA-5897 so I'm guessing there is
> some use case for this?
> Personally I would want the DC/rack settings to be as restricted as the
> cluster name, otherwise if a node could just join another data center without
> removing it's local information couldn't it mess up the token ranges? And
> suddenly the old data center/rack would loose 1 replica of all the data that
> the node contains.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15032835#comment-15032835 ] Paulo Motta commented on CASSANDRA-9474: Tests are still a bit unstable on 2.2 and 3.0, diverging from main branch tests #. Although it's probably a CI instability, I rebased and resubmitted to be sure. Will update when ready. > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031918#comment-15031918 ] Philip Thompson commented on CASSANDRA-9474: Yes, I believe this is good to commit w/ regards to CI > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15031209#comment-15031209 ] Robert Stupp commented on CASSANDRA-9474: - Good to commit WRT to CI? > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15030290#comment-15030290 ] Paulo Motta commented on CASSANDRA-9474: Rebased and updated NEWS.txt. Resubmitted tests. > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Commented] (CASSANDRA-9474) Validate dc information on startup
[ https://issues.apache.org/jira/browse/CASSANDRA-9474?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15029870#comment-15029870 ] Robert Stupp commented on CASSANDRA-9474: - Can you provide an updated text for NEWS.txt? 2.2, 3.0 and 3.1 also need to be rebased. > Validate dc information on startup > -- > > Key: CASSANDRA-9474 > URL: https://issues.apache.org/jira/browse/CASSANDRA-9474 > Project: Cassandra > Issue Type: Improvement > Environment: Cassandra 2.1.5 >Reporter: Marcus Olsson >Assignee: Marcus Olsson > Fix For: 3.1, 3.2, 2.1.x, 2.2.x, 3.0.x > > Attachments: CASSANDRA-9474-2.2.patch, CASSANDRA-9474-dtest.patch, > CASSANDRA-9474-trunk.patch, cassandra-2.1-9474.patch, > cassandra-2.1-dc_rack_healthcheck.patch > > > When using GossipingPropertyFileSnitch it is possible to change the data > center and rack of a live node by changing the cassandra-rackdc.properties > file. Should this really be possible? In the documentation at > http://docs.datastax.com/en/cassandra/2.1/cassandra/initialize/initializeMultipleDS.html > it's stated that you should ??Choose the name carefully; renaming a data > center is not possible??, but with this functionality it doesn't seem > impossible(maybe a bit hard with changing replication etc.). > This functionality was introduced by CASSANDRA-5897 so I'm guessing there is > some use case for this? > Personally I would want the DC/rack settings to be as restricted as the > cluster name, otherwise if a node could just join another data center without > removing it's local information couldn't it mess up the token ranges? And > suddenly the old data center/rack would loose 1 replica of all the data that > the node contains. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
