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.
Maybe we just add 'cman_tool configupdate' alias for 'cman_tool version -r0' ?
-r0 == Use what's in cluster.conf
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
Created attachment 433731 [details]
Drop version -r#; always use version from cluster.conf
Note that this patch maintains cmdline compatibility except for the warning message.
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.
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.
Verified while testing 617161.
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.