Send Linux-ha-cvs mailing list submissions to
linux-ha-cvs@lists.linux-ha.org
To subscribe or unsubscribe via the World Wide Web, visit
http://lists.community.tummy.com/mailman/listinfo/linux-ha-cvs
or, via email, send a message with subject or body 'help' to
[EMAIL PROTECTED]
You can reach the person managing the list at
[EMAIL PROTECTED]
When replying, please edit your Subject line so it is more specific
than "Re: Contents of Linux-ha-cvs digest..."
Today's Topics:
1. Linux-HA CVS: crm by andrew from
(linux-ha-cvs@lists.linux-ha.org)
2. Linux-HA CVS: crm by andrew from
(linux-ha-cvs@lists.linux-ha.org)
----------------------------------------------------------------------
Message: 1
Date: Mon, 3 Jul 2006 08:26:28 -0600 (MDT)
From: linux-ha-cvs@lists.linux-ha.org
Subject: [Linux-ha-cvs] Linux-HA CVS: crm by andrew from
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
linux-ha CVS committal
Author : andrew
Host :
Project : linux-ha
Module : crm
Dir : linux-ha/crm
Modified Files:
crm-1.0.dtd
Log Message:
Relax the DTD to avoid common ordering issues.
Clearly indicate what is and is not legal syntax for the cases that
cannot be detected by the DTD
===================================================================
RCS file: /home/cvs/linux-ha/linux-ha/crm/crm-1.0.dtd,v
retrieving revision 1.80
retrieving revision 1.81
diff -u -3 -r1.80 -r1.81
--- crm-1.0.dtd 3 Jul 2006 13:55:46 -0000 1.80
+++ crm-1.0.dtd 3 Jul 2006 14:26:28 -0000 1.81
@@ -5,35 +5,29 @@
Versionize DTD so we can validate against a specific version
Background
-The CIB is described quite well in section 5 of the crm.txt (checked into CVS
in the crm directory) so it is not repeated here.
-Suffice to say that it stores the configuration and runtime data required for
cluster-wide resource management in XML format.
+ The CIB is described quite well in section 5 of the crm.txt (checked into CVS
in the crm directory) so it is not repeated here.
+ Suffice to say that it stores the configuration and runtime data required for
cluster-wide resource management in XML format.
CIB: Information Structure
-The CIB is divided into two main sections: The "static" configuration part and
the "dynamic" status.
+ The CIB is divided into two main sections: The "static" configuration part
and the "dynamic" status.
-The configuration contains - surprisingly - the configuration of the cluster,
namely node attributes, resource instance configuration, and the constraints
which describe the dependencies between all these.
-To identify the most recent configuration available in the cluster, this
section is time-stamped with the unique timestamp of the last update.
+ The configuration contains - surprisingly - the configuration of the cluster,
namely node attributes, resource instance configuration, and the constraints
which describe the dependencies between all these.
+ To identify the most recent configuration available in the cluster, this
section is time-stamped with the unique timestamp of the last update.
-The status part is dynamically generated / updated by the CRM system and
represents the current status of the cluster; which nodes are up, down or
crashed, which resources are running where etc.
-The timestamps here represent when the last change went into this section.
+ The status part is dynamically generated / updated by the CRM system and
represents the current status of the cluster; which nodes are up, down or
crashed, which resources are running where etc.
-All timestamps are given in seconds since the epoch with millisecond precision.
+ Every information carrying object has an "id" tag, which is basically the
UUID of it, should we ever need to access it directly.
+ Unless otherwise stated, the id field is a short name consisting simple ascii
characters [a-zA-Z0-9_\-]
+ The exception is for resources because the LRM can support only id's of up to
64 characters.
-Every information carrying object has an "id" tag, which is basically the UUID
of it, should we ever need to access it directly.
-
-More details are given in the annotated DTD below.
+Other Notes
+ The description field in all elements is opaque to the CRM and is for
administrative comments.
TODO
* Is the version element necessary in <cib>? If we flag the DTD against which
the CIB validates, the version is implicit...
* Do we need to know about ping nodes...?
* The integer comparison type really should be number
-
-General Notes
-The description field in all elements is opaque to the CRM and is for
administrative comments.
-
-Unless otherwise stated, the id field is a short name consisting of up to 64
simple ascii characters [a-zA-Z0-9_\-]
-->
-
<!ELEMENT cib (configuration, status)>
<!ATTLIST cib
cib-last-written CDATA #IMPLIED
@@ -69,7 +63,6 @@
* ccm_transition stores the membership instance from the
ConsensusClusterMembership layer.
* cib_feature_revision is the feature set that this configuration requires
-->
-
<!ELEMENT configuration (crm_config, nodes, resources, constraints)>
<!--
@@ -78,7 +71,10 @@
Used to specify cluster-wide options.
The use of multiple cluster_property_set sections and time-based rule
expressions allows the the cluster to behave differently (for example) during
buisness hours than it does overnight.
+-->
+<!ELEMENT crm_config (cluster_property_set)*>
+<!--
Current crm_config options:
* transition_idle_timeout (interval, default=60s):
@@ -130,8 +126,6 @@
* FALSE : Ignore the action
This mostly effects the CRM's behavior when the interval for a recurring
action is changed.
-->
-
-<!ELEMENT crm_config (cluster_property_set)*>
<!ELEMENT cluster_property_set (rule*, attributes)>
<!ATTLIST cluster_property_set
id CDATA #REQUIRED
@@ -165,6 +159,7 @@
<!--
* class
+ Specifies the location and standard the resource script conforms to
* ocf
Most OCF RAs started out life as v1 Heartbeat resource agents.
These have all been ported to meet the OCF specifications.
@@ -208,8 +203,13 @@
* resource_stickiness
See the description of the default_resource_stickiness cluster attribute.
resource_stickiness allows you to override the cluster's default for the
individual resource.
+
+NOTE: primitive resources may contain at most one "operations" object.
+ The CRM will complain about your configuration if this criteria is not
met.
+ Please use crm_verify to ensure your configuration is valid.
+ The DTD is written this way to be order in-sensitive.
-->
-<!ELEMENT primitive (operations?, meta_attributes*, instance_attributes*)>
+<!ELEMENT primitive (operations|meta_attributes|instance_attributes)*>
<!ATTLIST primitive
id CDATA #REQUIRED
description CDATA #IMPLIED
@@ -267,8 +267,12 @@
* are all started on the same node, and
* are started and stopped in the correct (sequential) order
though either or both of these properties can be disabled.
+
+NOTE: Do not create empty groups.
+ They are temporarily supported because the GUI requires it but will be
removed as soon as possible.
+ The DTD is written this way to be order in-sensitive.
-->
-<!ELEMENT group (meta_attributes*, instance_attributes*, primitive*)>
+<!ELEMENT group (meta_attributes|instance_attributes|primitive)*>
<!ATTLIST group
id CDATA #REQUIRED
description CDATA #IMPLIED
@@ -302,9 +306,15 @@
Behaviour in response to a failed action or notificaiton is likely to be
improved in future releases.
See http://linux-ha.org/v2/Concepts/Clones for more information on notify
actions
+
+
+NOTE: Clones must contain exactly one primitive or one group resource.
+ The CRM will complain about your configuration if this criteria is not
met.
+ Please use crm_verify to ensure your configuration is valid.
+ The DTD is written this way to be order in-sensitive.
-->
-<!ELEMENT clone (meta_attributes*, instance_attributes*, (primitive|group))>
+<!ELEMENT clone (meta_attributes|instance_attributes|primitive|group)*>
<!ATTLIST clone
id CDATA #REQUIRED
description CDATA #IMPLIED
@@ -321,8 +331,14 @@
<!--
Master/Slave resources are a superset of Clones in that instances can also be
in one of two states.
The meaning of the states is specific to the resource.
+
+NOTE: master_slave must contain exactly one primitive resource OR one group
resource.
+ It may not contain both, nor may it contain neither.
+ The CRM will complain about your configuration if this criteria is not
met.
+ Please use crm_verify to ensure your configuration is valid.
+ The DTD is written this way to be order in-sensitive.
-->
-<!ELEMENT master_slave (meta_attributes*, instance_attributes*,
(primitive|group))>
+<!ELEMENT master_slave (meta_attributes|instance_attributes|primitive|group)*>
<!ATTLIST master_slave
id CDATA #REQUIRED
description CDATA #IMPLIED
@@ -401,9 +417,7 @@
Every constraint entry also has a 'lifetime' attribute, which expresses when
this constraint is applicable.
For example, a constraint may only be valid during certain times of the day,
or days of the week.
Eventually, we would like to be able to support constraints that only last
until events such as the next reboot or the next transition.
-
-->
-
<!ELEMENT constraints (rsc_order|rsc_colocation|rsc_location)*>
<!--
------------------------------
Message: 2
Date: Mon, 3 Jul 2006 09:15:30 -0600 (MDT)
From: linux-ha-cvs@lists.linux-ha.org
Subject: [Linux-ha-cvs] Linux-HA CVS: crm by andrew from
To: [EMAIL PROTECTED]
Message-ID: <[EMAIL PROTECTED]>
linux-ha CVS committal
Author : andrew
Host :
Project : linux-ha
Module : crm
Dir : linux-ha/crm/admin
Modified Files:
cibadmin.c
Log Message:
Support unversioned CIB update diffs via cibadmin
===================================================================
RCS file: /home/cvs/linux-ha/linux-ha/crm/admin/cibadmin.c,v
retrieving revision 1.54
retrieving revision 1.55
diff -u -3 -r1.54 -r1.55
--- cibadmin.c 19 Jun 2006 11:59:18 -0000 1.54
+++ cibadmin.c 3 Jul 2006 15:15:30 -0000 1.55
@@ -1,4 +1,4 @@
-/* $Id: cibadmin.c,v 1.54 2006/06/19 11:59:18 andrew Exp $ */
+/* $Id: cibadmin.c,v 1.55 2006/07/03 15:15:30 andrew Exp $ */
/*
* Copyright (C) 2004 Andrew Beekhof <[EMAIL PROTECTED]>
@@ -90,7 +90,7 @@
int operation_status = 0;
cib_t *the_cib = NULL;
-#define OPTARGS "V?o:QDUCEX:t:Srwlsh:MmBfbdRx:p"
+#define OPTARGS "V?o:QDUCEX:t:Srwlsh:MmBfbdRx:pP"
int
main(int argc, char **argv)
@@ -113,6 +113,7 @@
{CIB_OP_REPLACE, 0, 0, 'R'},
{CIB_OP_UPDATE, 0, 0, 'U'},
{CIB_OP_MODIFY, 0, 0, 'M'},
+ {"patch", 0, 0, 'P'},
{CIB_OP_DELETE, 0, 0, 'D'},
{CIB_OP_DELETE_ALT, 0, 0, 'd'},
{CIB_OP_BUMP, 0, 0, 'B'},
@@ -190,6 +191,9 @@
case 'Q':
cib_action = CIB_OP_QUERY;
break;
+ case 'P':
+ cib_action = CIB_OP_APPLY_DIFF;
+ break;
case 'S':
cib_action = CIB_OP_SYNC;
break;
------------------------------
_______________________________________________
Linux-ha-cvs mailing list
Linux-ha-cvs@lists.linux-ha.org
http://lists.community.tummy.com/mailman/listinfo/linux-ha-cvs
End of Linux-ha-cvs Digest, Vol 32, Issue 3
*******************************************
