Bug 216780 - Cryptic XML messages from system-config-cluster
Cryptic XML messages from system-config-cluster
Status: CLOSED NOTABUG
Product: Red Hat Cluster Suite
Classification: Red Hat
Component: redhat-config-cluster (Show other bugs)
4
All Linux
medium Severity medium
: ---
: ---
Assigned To: Jim Parsons
Cluster QE
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2006-11-21 18:22 EST by Robert Peterson
Modified: 2009-04-16 16:12 EDT (History)
1 user (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2006-11-27 11:02:21 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)

  None (edit)
Description Robert Peterson 2006-11-21 18:22:59 EST
Description of problem:
I have a cluster.conf I've been using for a long time on my RHEL4U4
cluster.  It may not be perfect, but the cluster runs.  However,
if I go into the system-config-cluster gui, I get a bunch of
error messages that are so cryptic I can't tell what's wrong
with the cluster.conf.  By the way, it's not so different from
the cluster.conf documented in the usage.txt file.

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

How reproducible:
Always

Steps to Reproduce:
Use this cluster.conf:

<?xml version="1.0"?>
<cluster config_version="1" name="bobs_roth">
        <fence_daemon clean_start="0" post_fail_delay="0" post_join_delay="1800"/>
        <clusternodes>
                <clusternode name="roth-01" votes="1">
                        <fence>
                                <method name="single">
                                        <device name="roth-apc" switch="1"
port="1"/>
                                </method>
                        </fence>
                </clusternode>
                <clusternode name="roth-02" votes="1">
                        <fence>
                                <method name="single">
                                        <device name="roth-apc" switch="1"
port="2"/>
                                </method>
                        </fence>
                </clusternode>
                <clusternode name="roth-03" votes="1">
                        <fence>
                                <method name="single">
                                        <device name="roth-apc" switch="1"
port="3"/>
                                </method>
                        </fence>
                </clusternode>
        </clusternodes>
        <fencedevices>
                <fencedevice agent="fence_apc" ipaddr="10.15.87.34" login="apc"
name="roth-apc" passwd="apc"/>
                <fencedevice agent="fence_baytech" ipaddr="10.15.87.33"
login="admin" name="baytech" passwd=""/>
                <fencedevice agent="fence_brocade" ipaddr="10.1.1.2"
login="user" name="brocade1" passwd="pw"/>
                <fencedevice agent="fence_brocade" ipaddr="10.1.1.3"
login="user" name="brocade2" passwd="pw"/>
                <fencedevice agent="fence_manual" name="human"/>
                <fencedevice agent="fence_cwigrid" name="iGrid"/>
        </fencedevices>
        <rm>
                <failoverdomains>
                        <failoverdomain name="igridnodes1" ordered="1"
restricted="1">
                                <failoverdomainnode name="roth-01" priority="1"/>
                                <failoverdomainnode name="roth-02" priority="2"/>
                        </failoverdomain>
                        <failoverdomain name="igridnodes2" ordered="1"
restricted="1">
                                <failoverdomainnode name="roth-02" priority="1"/>
                                <failoverdomainnode name="roth-01" priority="2"/>
                        </failoverdomain>
                </failoverdomains>
                <resources>
                        <ip address="10.15.84.250" monitor_link="1"/>
                        <ip address="10.15.84.251" monitor_link="1"/>
                </resources>
                <service autostart="1" domain="igridnodes1" name="10.15.84.251">
                        <ip ref="10.15.84.251"/>
                </service>
                <service autostart="1" domain="igridnodes2" name="10.15.84.250">
                        <ip ref="10.15.84.250"/>
                </service>
        </rm>
</cluster>

Go into the system-config-cluster gui.
  
Actual results:
/etc/cluster/cluster.conf:2: element cluster: Relax-NG validity error :
Expecting an element gulm, got nothing
/etc/cluster/cluster.conf:2: element cluster: Relax-NG validity error : Invalid
sequence in interleave
/etc/cluster/cluster.conf:2: element cluster: Relax-NG validity error : Element
cluster failed to validate content
/etc/cluster/cluster.conf:8: element device: validity error : IDREF attribute
name references an unknown ID "roth-apc"
/etc/cluster/cluster.conf:15: element device: validity error : IDREF attribute
name references an unknown ID "roth-apc"
/etc/cluster/cluster.conf:22: element device: validity error : IDREF attribute
name references an unknown ID "roth-apc"
/etc/cluster/cluster.conf fails to validate

Expected results:
How about telling me what I did wrong?  Or what it doesn't like?

Additional info:
It's easy to blow me off and say "He doesn't know what he'd doing" so
let's examine each of these messages one by one from a cluster admin's
point of view:

1. /etc/cluster/cluster.conf:2: element cluster: Relax-NG validity error :
Expecting an element gulm, got nothing

This is a dlm cluster.  It has nothing to do with gulm.  It doesn't say
what it really expected.  Is it expecting "lock_proto=lock_gulm"?
As far as I know, cluster.conf shouldn't need to know the lock proto
because GFS stores this info in the superblock, and the init scripts
take care of loading the necessary kernel modules.

2. /etc/cluster/cluster.conf:2: element cluster: Relax-NG validity error :
Invalid sequence in interleave

What's an "invalid sequence" to your typical sysadmin?
What does Relax-NH mean?  Nothing to me, but I'm not an xml expert.
Interleave doesn't appear anywhere in the cluster.conf file.  
So again, what does it not like?  What "sequence" is wrong?

3. /etc/cluster/cluster.conf:2: element cluster: Relax-NG validity error :
Element cluster failed to validate content

Validity error tells me absolutely nothing.  I get that it means
line 2, and the "cluster" tag.  But what doesn't it like about line 2?

4. /etc/cluster/cluster.conf:8: element device: validity error : IDREF attribute
name references an unknown ID "roth-apc"

Well, IDREF doesn't appear in cluster.conf.  "Name" appears on almost
every line.  Line 8's "name" specifies roth-apc, alright, but I don't
see anything wrong, but I'm not an xml parser either.
It'd be nice if it told me what it didn't like.  Like "fence device
roth-apc not found."  But it looks to be there to my untrained eyes.

5. /etc/cluster/cluster.conf:15: element device: validity error : IDREF
attribute name references an unknown ID "roth-apc"

Same as 4.

6. /etc/cluster/cluster.conf:22: element device: validity error : IDREF
attribute name references an unknown ID "roth-apc"
/etc/cluster/cluster.conf fails to validate

Same as 4.

I fully realize that we're just using an xml parser here, but to
users this is about as cryptic as humanly possible.  If it were in
Japanese, Hungarian, or Thai it would have made as much sense to me.

I also realize that we're heading away from s-c-c and onto conga,
and we definitely have higher priorities, but still...

Perhaps we need an xml-parser-to-sysadmin translation layer.
Comment 1 Jim Parsons 2006-11-27 11:02:21 EST
There is really no reason to be condescending here (which I feel your bug
description reeks of) for an error in a configuration file that you built by
hand, and then expect s-c-cluster to tell you what you did wrong. 
1) If you had built the original conf file in s-c-cluster, this error would not
exist.
2) Before reading a configuration file, s-c-cluster uses a RelaxNG schema file
to validate that the incoming file does not contain krud. The command used is:
'xmllint --relaxng cluster.ng cluster.conf' where cluster.ng is a file included
in the distribution in the src/misc directory. In fact, you can run this command
on your own. 
3) RelaxNG is much more lightweight a mechanism for checking xml validity than
the only other option which is XML Schema. That is a nightmare to maintain, and
the error messages it produces are as cryptic as the ones relaxng mode in
xmllint produces. One advantage to using RelaxNG, is that the guy who wrote and
maintains it works for Red Hat, and his error messages do improve with every
release...so, it is not the GUI tool producing the cryptic messages, it is the
external validation checker.
4) When a conf file fails, the relaxng error messages should be treated like a
compile or link error, where the FIRST error message is what needs to be
explored first. In the case of this file, the 'expecting gulm...' message is the
clue. Since you are not using GuLM, then there should be a cman tag, even if it
is an empty one: <cman/>. This is a requirement in the schema for
cluster.conf...if a file will work in a rhel4 cluster without either a gulm or
cman tag as a cman cluster, then this is a lucky accident - as it violates the
xml schema for cluster.conf.

If you add the <cman/> tag under <cluster> your errors will go away.

If you have a nasty failure of your schema, one quick way to troubleshoot it is
run xmllint directly and comment out huge chunks of the file to quickly localize
what section is actually giving you the issue - such as, everything under the
<rm> tag...then begin refining what is commented out until you find the true
culprit --- or just write the conf file in s-c-cluster from the get go.

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