[
https://issues.apache.org/jira/browse/CASSANDRA-10872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15059718#comment-15059718
]
Vasilis commented on CASSANDRA-10872:
-------------------------------------
No problem and thanks for looking into this.
I am not sure what the EOL of version 2.0 is, but it's probably worth
mentioning that this bug was introduced in 2.0.17 (the upgrade to versions up
to 2.0.16 did not behave like this at all). It is impossible (at least not in a
safe manner) for people to upgrade safely within 2.0.x, or to upgrade from
earlier versions (pre-2.0) to the latest Cassandra version, but through 2.0.x
(which is necessary in situations like this).
With that in mind, wouldn't it make more sense to create 2.0.18 with that fix
instead? Any thoughts on this?
> 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:
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
