cassandra-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Vasilis (JIRA)" <j...@apache.org>
Subject [jira] [Updated] (CASSANDRA-10872) Debian Package does not prompt the user to review the config files; it just replaces them causing trouble (since the daemon starts by default)
Date Wed, 16 Dec 2015 17:25:46 GMT

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

Mime
View raw message