[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)
[
https://issues.apache.org/jira/browse/CASSANDRA-10872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Michael Shuler updated CASSANDRA-10872:
---
Fix Version/s: (was: 3.0.x)
(was: 2.2.x)
(was: 2.1.x)
(was: 3.x)
> 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
> Labels: debian, packaging
>
> 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.15#6346)
[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)
[
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)
[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)
[ https://issues.apache.org/jira/browse/CASSANDRA-10872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Michael Shuler updated CASSANDRA-10872: --- Fix Version/s: 2.1.x > 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)
