Bug 617163 - cman dispatches config changes when there is no new config
cman dispatches config changes when there is no new config
Status: CLOSED CURRENTRELEASE
Product: Red Hat Enterprise Linux 6
Classification: Red Hat
Component: cluster (Show other bugs)
6.0
All Linux
low Severity medium
: rc
: ---
Assigned To: Fabio Massimo Di Nitto
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2010-07-22 07:17 EDT by Fabio Massimo Di Nitto
Modified: 2010-11-10 15:00 EST (History)
7 users (show)

See Also:
Fixed In Version: cluster-3.0.12-18.el6
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-11-10 15:00:03 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
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 11:17 EDT, Lon Hohberger
no flags Details | Diff

  None (edit)
Description Fabio Massimo Di Nitto 2010-07-22 07:17:44 EDT
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 09:47:33 EDT
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 10:01:06 EDT
Or...

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 11:17:32 EDT
Created attachment 433731 [details]
Drop version -r#; always use version from cluster.conf
Comment 10 Lon Hohberger 2010-07-22 11:18:31 EDT
Note that this patch maintains cmdline compatibility except for the warning message.
Comment 11 Lon Hohberger 2010-07-22 11:22:31 EDT
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:

   "-oopt"

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 04:50:56 EDT
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 10:56:26 EDT
Verified while testing 617161.
Comment 18 releng-rhel@redhat.com 2010-11-10 15:00:03 EST
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.