Bug 553762

Description of problem:

Current /usr/share/system-config-cluster/misc/cluster.ng is quite out of date, and so there are a lot of valid elements that can be in a cluster.conf that will generate Relax-NG validity error when parsed by system-config-cluster since they are not in it's XML schema.  We have numerous reports of different elements that trigger this right now:

At least three current BZ's filed through production support with an IT associated with them:
https://bugzilla.redhat.com/show_bug.cgi?id=520866
https://bugzilla.redhat.com/show_bug.cgi?id=530171
https://bugzilla.redhat.com/show_bug.cgi?id=552323

At least three more currently exist filed by customers directly onto Bugzilla:
https://bugzilla.redhat.com/show_bug.cgi?id=491676
https://bugzilla.redhat.com/show_bug.cgi?id=502012
https://bugzilla.redhat.com/show_bug.cgi?id=532766

It's rather tedious to track each one through a separate bug, so I wanted to propose that we make a sweep through currently valid options in cluster.conf and update cluster.ng wholesale will all valid options.  This should address the 6 bugs listed above, as well as hopefully prevent more that will likely pop up in the future as more people find and report them.



Version-Release number of selected component (if applicable):

# rpm -q system-config-cluster
system-config-cluster-1.0.57-1.5



How reproducible:

Easily, at will.



Steps to Reproduce:

1. Edit cluster.conf by hand (presumably to add features/tuning/etc not configurable by system-config-cluster) and add a valid XML option for a feature not in cluster.ng
2. Load up system-config-cluster



Actual results:

system-config-cluster will report Relax-NG validity errors for valid elements.



Expected results:

system-config-cluster should recognize all valid XML elements and not report errors for valid configuration options -- even if they are not able to be edited by the system-config-cluster tool itself.



Additional info:

I'm thinking this won't be too difficult and hoping we have an up to date schema defined somewhere so that we can quickly check that all up to date cluster.conf elements are defined in cluster.ng...  I hope that by doing one large sweep through this will save us a lot of time in the long run from filing bug after bug as customers run into and report these one by one.