[ https://issues.apache.org/jira/browse/CASSANDRA-10872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Vasilis updated CASSANDRA-10872: -------------------------------- Description: We run Cassandra 2.0.16 on Ubuntu 12.04 and were trying to upgrade to 2.0.17 due to CASSANDRA-9662. The problem is that during the upgrade the we were not prompted how to handle cassandra-env.sh and cassandra-rackdc.properties. The output from the upgrade: {panel} ... Setting up cassandra (2.0.17) ... Installing new version of config file /etc/cassandra/cassandra-env.sh ... Installing new version of config file /etc/cassandra/cassandra-rackdc.properties ... vm.max_map_count = 1048575 net.ipv4.tcp_keepalive_time = 300 ... {panel} This meant that the nodes started automatically after the install with the wrong DC name. I don't think that these config files should have been replaced without the admin being asked; this doesn't appear to comply with standard Debian packages. Secondly if CASSANDRA-2356 was implemented the problem would not be as severe; i.e. it would be possible to workaround this issue. Whereas currently, there is no way to prevent the node when upgraded from starting in the wrong DC. was: We run Cassandra 2.0.16 on Ubuntu 12.04 and were trying to upgrade to 2.0.17 due to CASSANDRA-9662. The problem is that during the upgrade the we were not prompted how to handle cassandra-env.sh and cassandra-rackdc.properties. The output from the upgrade: Setting up cassandra (2.0.17) ... Installing new version of config file /etc/cassandra/cassandra-env.sh ... Installing new version of config file /etc/cassandra/cassandra-rackdc.properties ... This meant that the nodes started automatically after the install with the wrong DC name. I don't think that these config files should have been replaced without the admin being asked; this doesn't appear to comply with standard Debian packages. Secondly if CASSANDRA-2356 was implemented the problem would not be as severe; i.e. it would be possible to workaround this issue. Whereas currently, there is no way to prevent the node when upgraded from starting in the wrong DC. > Debian Package does not prompt the user to review the config files; it just > replaces them causing trouble (since the daemon starts by default) > ---------------------------------------------------------------------------------------------------------------------------------------------- > > Key: CASSANDRA-10872 > URL: https://issues.apache.org/jira/browse/CASSANDRA-10872 > Project: Cassandra > Issue Type: Bug > Components: Packaging > Environment: Ubuntu 12.04, Cassandra 2.0.16 -> 2.0.17 > Reporter: Vasilis > Assignee: Michael Shuler > Priority: Critical > Fix For: 2.1.x > > > We run Cassandra 2.0.16 on Ubuntu 12.04 and were trying to upgrade to 2.0.17 > due to CASSANDRA-9662. The problem is that during the upgrade the we were not > prompted how to handle cassandra-env.sh and cassandra-rackdc.properties. > The output from the upgrade: > {panel} > ... > Setting up cassandra (2.0.17) ... > Installing new version of config file /etc/cassandra/cassandra-env.sh ... > Installing new version of config file > /etc/cassandra/cassandra-rackdc.properties ... > vm.max_map_count = 1048575 > net.ipv4.tcp_keepalive_time = 300 > ... > {panel} > This meant that the nodes started automatically after the install with the > wrong DC name. > I don't think that these config files should have been replaced without the > admin being asked; this doesn't appear to comply with standard Debian > packages. > Secondly if CASSANDRA-2356 was implemented the problem would not be as > severe; i.e. it would be possible to workaround this issue. Whereas > currently, there is no way to prevent the node when upgraded from starting in > the wrong DC. -- This message was sent by Atlassian JIRA (v6.3.4#6332)