[Linux-HA] crm_verify issues

[Andrew Beekhof]

On 2/13/07, Terry L. Inzauro <tinzauro at ha-solutions.net> wrote:
> Andreas Kurz wrote:
> > On 2/13/07, Terry L. Inzauro <tinzauro at ha-solutions.net> wrote:
> >> list,
> >>
> >> i've been testing some different configurations for my cluster over
> >> the past few days and i have run
> >> into an odd issue.
> >>
> >> destiny (node 1)
> >> ------------------
> >> destiny heartbeat # crm_verify -V -V -V -x /var/lib/heartbeat/crm/cib.xml
> >> crm_verify[20310]: 2007/02/13_08:49:25 info: main: =#=#=#=#= Getting
> >> XML =#=#=#=#=
> >> crm_verify[20310]: 2007/02/13_08:49:25 notice: main: Required feature
> >> set: 1.1
> >> element cib: validity error : Element cib content does not follow the
> >> DTD, expecting (configuration
> >> , status), got (configuration )
> >> crm_verify[20310]: 2007/02/13_08:49:25 ERROR: validate_with_dtd: CIB
> >> does not validate against
> >> /usr/lib/heartbeat/crm.dtd
> >> crm_verify[20310]: 2007/02/13_08:49:25 ERROR: main: CIB did not pass
> >> DTD validation
> >> crm_verify[20310]: 2007/02/13_08:49:25 notice: cluster_option: Using
> >> default value 'stop' for
> >> cluster option 'no-quorum-policy'
> >> crm_verify[20310]: 2007/02/13_08:49:25 notice: cluster_option: Using
> >> default value '60s' for cluster
> >> option 'cluster-delay'
> >> crm_verify[20310]: 2007/02/13_08:49:25 notice: cluster_option: Using
> >> default value '-1' for cluster
> >> option 'pe-error-series-max'
> >> crm_verify[20310]: 2007/02/13_08:49:25 notice: cluster_option: Using
> >> default value '-1' for cluster
> >> option 'pe-warn-series-max'
> >> crm_verify[20310]: 2007/02/13_08:49:25 notice: cluster_option: Using
> >> default value '-1' for cluster
> >> option 'pe-input-series-max'
> >> crm_verify[20310]: 2007/02/13_08:49:25 notice: cluster_option: Using
> >> default value 'true' for
> >> cluster option 'startup-fencing'
> >> Errors found during check: config not valid
> >>
> >> roxetta (node 2)
> >> ---------------
> >> roxetta crm # crm_verify -V -V -V -x /var/lib/heartbeat/crm/cib.xml
> >> crm_verify[20868]: 2007/02/13_10:22:05 info: main: =#=#=#=#= Getting
> >> XML =#=#=#=#=
> >> crm_verify[20868]: 2007/02/13_10:22:05 notice: main: Required feature
> >> set: 1.1
> >> crm_verify[20868]: 2007/02/13_10:22:05 notice: cluster_option: Using
> >> default value 'stop' for
> >> cluster option 'no-quorum-policy'
> >> crm_verify[20868]: 2007/02/13_10:22:05 notice: cluster_option: Using
> >> default value '60s' for cluster
> >> option 'cluster-delay'
> >> crm_verify[20868]: 2007/02/13_10:22:05 notice: cluster_option: Using
> >> default value '-1' for cluster
> >> option 'pe-error-series-max'
> >> crm_verify[20868]: 2007/02/13_10:22:05 notice: cluster_option: Using
> >> default value '-1' for cluster
> >> option 'pe-warn-series-max'
> >> crm_verify[20868]: 2007/02/13_10:22:05 notice: cluster_option: Using
> >> default value '-1' for cluster
> >> option 'pe-input-series-max'
> >> crm_verify[20868]: 2007/02/13_10:22:05 notice: cluster_option: Using
> >> default value 'true' for
> >> cluster option 'startup-fencing'
> >>
> >>
> >>
> >> why does one validate properly and the other does not?  in fact,
> >> heartbeat starts fine as well as my
> >> resources on roxetta.....just not on destiny.......yes, i have made
> >> certain they are the same file.
> >
> > To be sure that destiny has the same files as roxetta you could simply
> > shut down heartbeat on destiny, delete all files in
> > /var/lib/heartbeat/crm/ on destiny and start heartbeat again. As
> > roxetta is the DC it syncs the current cib to destiny.
> >
> > If heartbeat on destiny still complains, some logfile inspection
> > should be done ;-)
> >
> > Regards,
> > Andreas
> >
> >>
> >>
> >> Validation:
> >> -------------
> >> roxetta crm # scp cib.xml root at destiny:
> >> Password:
> >> cib.xml
> >>
> >> destiny heartbeat # diff /root/cib.xml /var/lib/heartbeat/crm/cib.xml
> >> destiny heartbeat #
> >>
> >>
> >>
> >> any help would be greatly appreciated.
> >>
> >>
> >>
> >> _Terry
> >>
> >> _______________________________________________
> >> Linux-HA mailing list
> >> Linux-HA at lists.linux-ha.org
> >> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> >> See also: http://linux-ha.org/ReportingProblems
> >>
>
>
> for clarification:
> ------------------
> as per this page ( http://www.linux-ha.org/DesignatedController ), the "DC" is the "boss of the
> bosses" (for lack of creativity) that is elected by 'all' of the fully connected cluster nodes.
>
> when changing the contents of cib.xml via cibadmin(8), is this (the DC) the the node that you should
> perform said changes on?

you, as the admin, can initiate the changes from any node

we, as the cluster, will (by default) then forward them on to the DC
who will actually apply them and push them out to all its peers.

hope that helps

> the wording is a little ambiguous.
>
>         "The Designated Coordinator is also the location of All changes to the                                  ClusterInformationBase,
> including requests to migrate resources to and from any ClusterNode"
>
> if you should only use cibadmin(8) on the DC, what will happen if you use cibadmin(8) on another
> fully connected cluster node?
>
>
> for more clarification:
> -----------------------
> will the UUID of cluster nodes ever change?
> if yes to the question above, what would cause the UUID of a cluster node to change?
>
>
> i ask because i noticed, in cib.xml, on the DC that there were two node names with different UUID's.
>  neither of which matched the original UUID that was populated originally..... so i used crm_uuid to
> get the "current" UUID of each node and filled it in by hand.  then all magically started working
> again.
>
>
> keep in mind that crm_verify still errors but crm starts properly.
>
>
> best regards,
>
>
> _Terry
>
>
>
> _______________________________________________
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>