Bug 617163 - cman dispatches config changes when there is no new config
Summary: cman dispatches config changes when there is no new config
Alias: None
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cluster   
(Show other bugs)
Version: 6.0
Hardware: All Linux
Target Milestone: rc
: ---
Assignee: Fabio Massimo Di Nitto
QA Contact: Cluster QE
Depends On:
TreeView+ depends on / blocked
Reported: 2010-07-22 11:17 UTC by Fabio Massimo Di Nitto
Modified: 2010-11-10 20:00 UTC (History)
7 users (show)

Fixed In Version: cluster-3.0.12-18.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2010-11-10 20:00:03 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Drop version -r#; always use version from cluster.conf (2.69 KB, patch)
2010-07-22 15:17 UTC, Lon Hohberger
no flags Details | Diff

Description Fabio Massimo Di Nitto 2010-07-22 11:17:44 UTC
when issuing cman_tool version -rX, a new configuration is loaded and a configuration change is dispatched to all daemons to reload the new config.

In case where: cluster.conf is set to value X and cman_tool version -rX+1 (that is NOT available in the cluster), cman will still dispatch a new config notification. this should not happen till X+1 is loaded.

Comment 1 Lon Hohberger 2010-07-22 13:47:33 UTC
Maybe we just add 'cman_tool configupdate' alias for 'cman_tool version -r0' ?

-r0 == Use what's in cluster.conf

Comment 2 Lon Hohberger 2010-07-22 14:01:06 UTC

cman_tool version -r  = reload config (e.g. -r0)
cman_tool version -rX = reload config, print warning that the 'X'
                        is deprecated and is ignored

Comment 9 Lon Hohberger 2010-07-22 15:17:32 UTC
Created attachment 433731 [details]
Drop version -r#; always use version from cluster.conf

Comment 10 Lon Hohberger 2010-07-22 15:18:31 UTC
Note that this patch maintains cmdline compatibility except for the warning message.

Comment 11 Lon Hohberger 2010-07-22 15:22:31 UTC
Due to the way getopt() works (shifting args around), it's difficult to catch this case in a sane way:

   cman_tool version -r -Dnone 123

This produces the warning about -r# deprecated (instead of an error in parsing the cmdline) but I don't really consider this a big issue.

The :: operator means an option arg might have an option, but requires:


That is, "-o opt" does not work with the getopt GNU extension for optional arguments.  Now, the ':' (required arg) option by contrast accepts both "-oopt" and "-o opt".

Consequently, the patch checks for both uses.  The alternative is to turn of opterr, which is not a good idea in my opinion.

Comment 14 Fabio Massimo Di Nitto 2010-07-27 08:50:56 UTC
Note for QE: the test cases for those fixes are complex. I´ll need to prepare a proper document comparing before and after the fix.

Both Lon and I did test the fixes so I have built for Snap9. Stay tuned.

Comment 17 Dean Jansa 2010-08-24 14:56:26 UTC
Verified while testing 617161.

Comment 18 releng-rhel@redhat.com 2010-11-10 20:00:03 UTC
Red Hat Enterprise Linux 6.0 is now available and should resolve
the problem described in this bug report. This report is therefore being closed
with a resolution of CURRENTRELEASE. You may reopen this bug report if the
solution does not work for you.

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