Bug 149124 - Cannot update version number of cluster.conf file: prevents use of ccs_tool update
Cannot update version number of cluster.conf file: prevents use of ccs_tool u...
Status: CLOSED NEXTRELEASE
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: redhat-config-cluster (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jim Parsons
Cluster QE
:
: 158419 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2005-02-18 18:17 EST by Paul Kennedy
Modified: 2015-04-19 20:46 EDT (History)
3 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2005-05-11 15:48:10 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Paul Kennedy 2005-02-18 18:17:59 EST
Description of problem:
After saving changes to a configuration file, cannot use "ccs_tool
update" because the GUI does not change the revision level of the
configuration file. 

Version-Release number of selected component (if applicable):
system-config-cluster-0.9.5-1.0

Steps to Reproduce:
1. Change configuration file using system-config-cluster.
2. Save file /etc/cluster/cluster.conf. NOTE: Because of another
   bug, use "Save As" to ensure that the config file is changed.
3. At command line prompt: enter the following:
   ccs_tool update /etc/cluster/cluster.conf
  
Actual results:
root@tng3-4 mnt]# ccs_tool update /etc/cluster/cluster.conf
Proposed updated config file does not have greater version number.
  Current config_version :: 1
  Proposed config_version:: 1

Expected results:
Successful update

Additional info:
Comment 1 Jim Parsons 2005-03-01 11:27:58 EST
config_version can now be updated , but needs to not autoincrement upon save if
user has modifed current value.
Comment 2 Derek Anderson 2005-03-11 14:20:02 EST
User can now manually set config_version.  It is not currently
autoincrementing if the user makes another config change without
modifying config_version.  So that still needs to be done, if I
understand correctly.

system-config-cluster-0.9.11-1.0
Comment 3 Jim Parsons 2005-03-14 22:07:06 EST
Fixed completely in 0.9.12
Comment 4 Derek Anderson 2005-03-15 14:39:27 EST
In 0.9.12 if the user specifies a config_version it is incremented by
one.  In this case the user should get exactly what they ask for. 
e.g. specify version 70 and it is written as 71, should write 70.
Comment 5 Jim Parsons 2005-03-28 06:23:42 EST
This is finally fixed, and a new button has been added to the UI if the UI is
run on a quorate cluster member that allows the new cfg to be propogated to all
nodes.

Fixed in 0.9.17-1.0
Comment 6 Corey Marthaler 2005-04-18 15:11:47 EDT
partially fixed.

If someone specifies a version of 1 or less (including all negative numbers), it
will jump one when it does the save, however, all other numbers greater than 1,
it will not.
Comment 7 Jim Parsons 2005-04-28 10:55:43 EDT
Now negative numbers are not allowed, so this issue is moot. Fixed in 0.9.42
Comment 8 Corey Marthaler 2005-04-28 15:31:29 EDT
If I change the version from say 5 down to 1 and then save it, it will work and
my new version is 1 (which is good), if I then do nothing to alter the config
and save again, it will bump up to 2 (again I would argue expected behavior),
after that if I just continue to save over and over again without changing the
config at all, it will only bump the config version every _other_ time. Every
time there is a save, it should always bump the version UNLESS the config
version is what is changed, at which point the version should be _EXACTLY_ what
the user defined as the version (as long as it's an integer from 1 to 9999) or
zero if we allow it.
Comment 9 Jim Parsons 2005-05-09 15:32:30 EDT
Finally all fixed in 0.9.50-1.0
Comment 10 Corey Marthaler 2005-05-11 15:48:10 EDT
fix verified.
Comment 11 Corey Marthaler 2005-05-25 15:02:23 EDT
*** Bug 158419 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.