Bug 615929

Jing says:

[lhh@localhost jing-20090818]$ java -jar bin/jing.jar ~/cluster.rng.in ./cluster.conf_fail
/sandbox/lhh/jing/jing-20090818/./cluster.conf_fail:25:21: error: attribute "node" not allowed here; expected attribute "action", "aptpl", "auth", "channel_address", "cipher", "cmd_prompt", "community", "cserver", "debug", "device", "devices", "domain", "drac_version", "exec", "hash", "help", "hmc_version", "identity_file", "inet4_only", "inet6_only", "io_fencing", "ip_family", "ipaddr", "ipport", "key", "key_file", "lanplus", "logfile", "login", "managed", "method", "module_name", "multicast_address", "nodename", "option", "partition", "passwd", "passwd_script", "port", "retrans", "ribcl", "rpowerpath", "secure", "separator", "serial_device", "serial_params", "servers", "snmp_auth_prot", "snmp_priv_passwd", "snmp_priv_passwd_script", "snmp_priv_prot", "snmp_sec_level", "snmp_version", "ssl", "switch", "timeout", "udpport", "use_uuid", "verbose", "version", "vmware_datacenter" or "vmware_type"
/sandbox/lhh/jing/jing-20090818/./cluster.conf_fail:27:21: error: attribute "node" not allowed here; expected attribute "action", "aptpl", "auth", "channel_address", "cipher", "cmd_prompt", "community", "cserver", "debug", "device", "devices", "domain", "drac_version", "exec", "hash", "help", "hmc_version", "identity_file", "inet4_only", "inet6_only", "io_fencing", "ip_family", "ipaddr", "ipport", "key", "key_file", "lanplus", "logfile", "login", "managed", "method", "module_name", "multicast_address", "nodename", "option", "partition", "passwd", "passwd_script", "port", "retrans", "ribcl", "rpowerpath", "secure", "separator", "serial_device", "serial_params", "servers", "snmp_auth_prot", "snmp_priv_passwd", "snmp_priv_passwd_script", "snmp_priv_prot", "snmp_sec_level", "snmp_version", "ssl", "switch", "timeout", "udpport", "use_uuid", "verbose", "version", "vmware_datacenter" or "vmware_type"

Looking at the fence_scsi script, the parameter "node" should be "nodename".  Since the <fencedevice> is failing because of this, this trickles up to the IDREF error when using xmllint.

Actually, "node" I don't think is ever used by a fencing agent; it's always "nodename".

Here's the line from fence_scsi:

http://git.fedorahosted.org/git/?p=cluster.git;a=blob;f=fence/agents/scsi/fence_scsi.pl;h=992a3ebb813f8c649ff0293d3b8ed9b9364288f0;hb=RHEL6#l545

Changing node -> nodename causes above cluster.conf to validate correctly.

the fix committed in luci.git 3177c4dd861060b6bec1b3510fcf041334c1fff7
does not solve the issue.

adding a fence_scsi device with Node name = foo returns an error:

No value for required attribute "node" was given for fence "scsi_fence"

It looks like the fix was not complete.

It should be fully completed in 6afbe5ac3ed48b589ba4375065a4d8aa35eb3927

Fabio,

can you verify that this works?

Thanks,
Chris

confirmed that the new fix works as expected

The config file listed above is a bad config file that was generated with a past version of luci with the bug.  If you create a new cluster in luci and created a fence scsi device it should be using the "nodename" tag inside <fencedevice>.

So if you create a cluster.conf and add a fence_scsi device and look at the cluster.conf and if the line looks something like this:

...
        <fencedevices>
                <fencedevice agent="fence_scsi" name="scsi_fence"
node="rhel6-node1"/>
                <fencedevice agent="fence_scsi" name="scsi_fence2"
node="rhel6-node2"/>
        </fencedevices>
...

Then luci is doing it wrong, it should look like this (notice node->nodename):

...
        <fencedevices>
                <fencedevice agent="fence_scsi" name="scsi_fence"
nodename="rhel6-node1"/>
                <fencedevice agent="fence_scsi" name="scsi_fence2"
nodename="rhel6-node2"/>
        </fencedevices>
...

verified

gotcha, parameter name is "nodename" in the cluster.conf currently generated by luci.

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.