xml/crm-1.0.dtd

7 months ago

author
Andrew Beekhof <abeekhof@suse.de>
date
Wed Nov 12 13:19:30 2008 +0100
changeset 13694
366b14d79780
permissions
-rw-r--r--

Hg: Automated merge

     1 <?xml version="1.0" encoding="UTF-8" ?>
     2 <!--
     3 GLOBAL TODOs:
     5 Versionize DTD so we can validate against a specific version
     7 Background
     8  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.
     9  Suffice to say that it stores the configuration and runtime data required for cluster-wide resource management in XML format.
    11 CIB: Information Structure
    12  The CIB is divided into two main sections: The "static" configuration part and the "dynamic" status.
    14  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.
    15  To identify the most recent configuration available in the cluster, this section is time-stamped with the unique timestamp of the last update.
    17  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.
    19  Every information carrying object has an "id" tag, which is basically the UUID of it, should we ever need to access it directly.
    20  Unless otherwise stated, the id field is a short name consisting simple ascii characters [a-zA-Z0-9_\-]
    21  The exception is for resources because the LRM can support only id's of up to 64 characters.
    23 Other Notes
    24  The description field in all elements is opaque to the CRM and is for administrative comments.
    26 TODO
    27  * Figure out a sane way to version the DTD
    28  * Do we need to know about ping nodes...?
    29  * The integer comparison type really should be number
    30 -->
    31 <!ELEMENT cib (configuration, status)>
    32 <!ATTLIST cib
    33           cib-last-written CDATA        #IMPLIED
    35           admin_epoch  CDATA        #REQUIRED
    36           epoch        CDATA        #REQUIRED
    37           num_updates  CDATA        #REQUIRED
    38           num_peers    CDATA        #IMPLIED        
    40           cib_feature_revision  CDATA   #IMPLIED
    41           crm_feature_set       CDATA   #IMPLIED
    42           remote_access_port    CDATA   #IMPLIED        
    44           dc_uuid        CDATA             #IMPLIED
    45           ccm_transition CDATA             #IMPLIED
    46           have_quorum    (true|yes|1|false|no|0)  'false'
    47           ignore_dtd     (true|yes|1|false|no|0)  #IMPLIED
    49           validate-with  CDATA    #IMPLIED        
    50           generated      CDATA    #IMPLIED        
    51           crm-debug-origin CDATA    #IMPLIED>
    53 <!--
    54 The CIB's version is a tuple of admin_epoch, epoch and num_updates (in that order).
    56 This is used when applying updates from the master CIB instance.
    58 Additionally, num_peers and have_quorum are used during the election process to determin who has the latest configuration.
    59  * num_updates is incremented every time the CIB changes.
    60  * epoch is incremented after every DC election.
    61  * admin_epoch is exclusivly for the admin to change.
    62  * num_peers is the number of CIB instances that we can talk to
    63  * have_quorum is derived from the ConsensusClusterMembership layer
    64  * dc_uuid stored the UUID of the current DesignatedController
    65  * ccm_transition stores the membership instance from the ConsensusClusterMembership layer.
    66  * cib_feature_revision is the feature set that this configuration requires
    67 -->
    68 <!ELEMENT configuration (crm_config, nodes, resources, constraints)>
    70 <!--
    71 crm_config
    73 Used to specify cluster-wide options.
    75 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.
    76 -->
    77 <!ELEMENT crm_config (cluster_property_set)*>
    79 <!--
    80 Current crm_config options:
    82  * transition_idle_timeout (interval, default=60s):
    83    If no activity is recorded in this time, the transition is deemed failed as are all sent actions that have not yet been confirmed complete.
    84    If any operation initiated has an explicit higher timeout, the higher value applies.
    86  * symmetric_cluster (boolean, default=TRUE):
    87    If true, resources are permitted to run anywhere by default.
    88    Otherwise, explicit constraints must be created to specify where they can run.
    90  * stonith_enabled (boolean, default=FALSE):
    91    If true, failed nodes will be fenced.
    93  * no_quorum_policy (enum, default=stop)
    94    * ignore - Pretend we have quorum
    95    * freeze - Do not start any resources not currently in our partition.
    96      Resources in our partition may be moved to another node within the partition
    97      Fencing is disabled
    98    * stop - Stop all running resources in our partition
    99      Fencing is disabled
   101  * default_resource_stickiness
   102    Do we prefer to run on the existing node or be moved to a "better" one?
   103    * 0 : resources will be placed optimally in the system.
   104      This may mean they are moved when a "better" or less loaded node becomes available.
   105      This option is almost equivalent to auto_failback on except that the resource may be moved to other nodes than the one it was previously active on.
   106    * value > 0 : resources will prefer to remain in their current location but may be moved if a more suitable node is available.
   107      Higher values indicate a stronger preference for resources to stay where they are.
   108    * value < 0 : resources prefer to move away from their current location.
   109      Higher absolute values indicate a stronger preference for resources to be moved.
   110    * INFINITY : resources will always remain in their current locations until forced off because the node is no longer eligible to run the resource (node shutdown, node standby or configuration change).
   111      This option is almost equivalent to auto_failback off except that the resource may be moved to other nodes than the one it was previously active on.
   112    * -INFINITY : resources will always move away from their current location.
   114  * is_managed_default (boolean, default=TRUE)
   115    Unless the resource's definition says otherwise,
   116    * TRUE : resources will be started, stopped, monitored and moved as necessary/required
   117    * FALSE : resources will not started if stopped, stopped if started nor have any recurring actions scheduled.
   119  * stop_orphan_resources (boolean, default=TRUE (as of release 2.0.6))
   120    If a resource is found for which we have no definition for;
   121    * TRUE : Stop the resource
   122    * FALSE : Ignore the resource
   123    This mostly effects the CRM's behavior when a resource is deleted by an admin without it first being stopped.
   125  * stop_orphan_actions (boolean, default=TRUE)
   126    If a recurring action is found for which we have no definition for;
   127    * TRUE : Stop the action
   128    * FALSE : Ignore the action
   129    This mostly effects the CRM's behavior when the interval for a recurring action is changed.
   130 -->
   131 <!ELEMENT cluster_property_set (rule*, attributes)>
   132 <!ATTLIST cluster_property_set
   133           id                CDATA        #REQUIRED
   134           score             CDATA        #IMPLIED>
   136 <!ELEMENT nodes       (node*)>
   138 <!--
   139  * id    : the node's UUID.
   140  * uname : the result of uname -n
   141  * type  : should either be "normal" or "member" for nodes you with to run resources 
   142    "normal" is preferred as of version 2.0.4
   144 Each node can also have additional "instance" attributes.
   145 These attributes are completely arbitrary and can be used later in constraints.
   146 In this way it is possible to define groups of nodes to which a constraint can apply.
   148 It is also theoretically possible to have a process on each node which updates these values automatically.
   149 This would make it possible to have an attribute that represents "connected to SAN subsystem" or perhaps "system_load (low|medium|high)".
   151 Ideally it would be possible to have the CRMd on each node gather some of this information and automatically populate things like architecture and OS/kernel version.
   152 -->
   153 <!ELEMENT node (instance_attributes*)>
   154 <!ATTLIST node
   155           id            CDATA         #REQUIRED
   156           uname         CDATA         #REQUIRED
   157           description   CDATA         #IMPLIED
   158           type          (normal|member|ping) #REQUIRED>
   160 <!ELEMENT resources   (primitive|group|clone|master_slave)*>
   162 <!--
   163  * class
   164    Specifies the location and standard the resource script conforms to
   165    * ocf
   166      Most OCF RAs started out life as v1 Heartbeat resource agents.
   167      These have all been ported to meet the OCF specifications.
   168      As an added advantage, in accordance with the OCF spec, they also describe the parameters they take and what their defaults are.
   169      It is also easier to configure them as each part of the configuration is passed as its own parameter.
   170      In accordance with the OCF spec, each parameter is passed to the RA with an OCF_RESKEY_ prefix.
   171      So ip=192.168.1.1 in the CIB would be passed as OCF_RESKEY_ip=192.168.1.1.
   172      Located under /usr/lib/ocf/resource.d/heartbeat/.
   173    * lsb
   174      Most Linux init scripts conform to the LSB specification.
   175      The class allows you to use those that do as resource agents controlled by Heartbeat.
   176      Located in /etc/init.d/.
   177    * heartbeat
   178      This class gives you access to the v1 Heartbeat resource agents and allows you to reuse any custom agents you may have written.
   179      Located at /etc/heartbeat/resource.d/ or /etc/ha.d/resource.d.
   181  * type : The name of the ResourceAgent you wish to use.
   183  * provider
   184    The OCF spec allows multiple vendors to supply the same ResourceAgent.
   185    To use the OCF resource agents supplied with Heartbeat, you should specify heartbeat here
   187  * is_managed : Is the ClusterResourceManager in control of this resource.
   188    * true : (default) the resource will be started, stopped, monitored and moved as necessary/required
   189    * false : the resource will not started if stopped, stopped if started nor have any recurring actions scheduled.
   190      The resource may still be referenced in colocation constraints and ordering constraints (though obviously if no actions are performed on it then it will prevent the action on the other resource too)
   192  * restart_type
   193    Used when the other side of an ordering dependency is restarted/moved.
   194    * ignore : the default.
   195      Don't do anything extra.
   196    * restart
   197      Use this for example to have a restart of your database also trigger a restart of your web-server.
   198    * multiple_active
   199      Used when a resource is detected as being active on more than one machine.
   200      The default value, stop_start, will stop all instances and start only 1
   201    * block : don't do anything, wait for the administrator
   202    * stop_only : stop all the active instances
   203    * stop_start : start the resource on one node after having stopped all the active instances
   205  * resource_stickiness
   206    See the description of the default_resource_stickiness cluster attribute.
   207    resource_stickiness allows you to override the cluster's default for the individual resource.
   209 NOTE: primitive resources may contain at most one "operations" object.
   210       The CRM will complain about your configuration if this criteria is not met.
   211       Please use crm_verify to ensure your configuration is valid.
   212       The DTD is written this way to be order in-sensitive.
   213 -->
   214 <!ELEMENT primitive (operations|meta_attributes|instance_attributes)*>
   215 <!ATTLIST primitive
   216           id                CDATA        #REQUIRED
   217           description       CDATA        #IMPLIED
   218           class             (ocf|lsb|heartbeat|stonith) #REQUIRED
   219           type              CDATA        #REQUIRED
   220           provider          CDATA        #IMPLIED
   222           is_managed            CDATA                            #IMPLIED
   223           restart_type          (ignore|restart)                 'ignore'
   224           multiple_active       (stop_start|stop_only|block)     'stop_start'
   225           resource_stickiness   CDATA                             #IMPLIED>
   226 <!--
   227 This allows us to specify how long an action can take
   229  * name : the name of the operation.
   230    Supported operations are start, stop, & monitor
   232  * start_delay : delay the operation after starting the resource
   233    By default this value is in milliseconds, however you can also specify a value in seconds like so timeout="5s". Used for the monitor operation.
   235  * timeout : the maximum period of time before considering the action failed.
   236    By default this value is in milliseconds, however you can also specify a value in seconds like so timeout="5s".
   238  * interval : This currently only applies to monitor operations and specifies how often the LRM should check the resource is active.
   239    The same notation for timeout applies.
   241  * prereq : What conditions need to be met before this action can be run
   242    * nothing : This action can be performed at any time
   243    * quorum : This action requires the partition to have quorum
   244    * fencing : This action requires the partition to have quorum and any fencing operations to have completed before it can be executed
   246  * on_fail : The action to take if this action ever fails.
   247    * nothing : Pretend the action didnt actually fail
   248    * block : Take no further action on the resource - wait for the administrator to resolve the issue
   249    * restart : Stop the resource and re-allocate it elsewhere
   250    * stop : Stop the resource and DO NOT re-allocate it elsewhere
   251    * fence : Currently this means fence the node on which the resource is running.
   252      Any other resources currently active on the machine will be migrated away before fencing occurs.
   254 Only one entry per supported action+interval is currently permitted.
   255 Parameters specific to each operation can be passed using the instance_attributes section.
   256 -->
   257 <!ELEMENT operations (op*)>
   258 <!ELEMENT op (meta_attributes|instance_attributes)*>
   259 <!ATTLIST op
   260           id            CDATA         #REQUIRED
   261           name          CDATA         #REQUIRED
   262           description   CDATA         #IMPLIED
   263           interval      CDATA         #IMPLIED
   264           timeout       CDATA         #IMPLIED
   265           start_delay   CDATA         '0'
   266           disabled      (true|yes|1|false|no|0)        'false'
   267           role          (Master|Slave|Started|Stopped) 'Started'
   268           prereq        (nothing|quorum|fencing)       #IMPLIED
   269           on_fail       (ignore|block|stop|restart|fence)     #IMPLIED>
   270 <!--
   271 Use this to emulate v1 type Heartbeat groups.
   272 Defining a resource group is a quick way to make sure that the resources:
   273  * are all started on the same node, and
   274  * are started and stopped in the correct (sequential) order
   275 though either or both of these properties can be disabled.
   277 NOTE: Do not create empty groups.  
   278       They are temporarily supported because the GUI requires it but will be removed as soon as possible.
   279       The DTD is written this way to be order in-sensitive.
   280 -->
   281 <!ELEMENT group (meta_attributes|instance_attributes|primitive)*>
   282 <!ATTLIST group
   283           id            CDATA               #REQUIRED
   284           description   CDATA               #IMPLIED
   286           is_managed            CDATA                         #IMPLIED
   287           restart_type          (ignore|restart)              'ignore'
   288           multiple_active       (stop_start|stop_only|block)  'stop_start'
   289           resource_stickiness   CDATA			      #IMPLIED
   291           ordered               (true|yes|1|false|no|0)       'true'
   292           collocated            (true|yes|1|false|no|0)       'true'>
   293 <!--
   294 Clones are intended as a mechanism for easily starting a number of resources (such as a web-server) with the same configuration.
   295 As an added benefit, the number that should be started is an instance parameter and when combined with time-based constraints, allows the administrator to run more instances during peak times and save on resources during idle periods.
   297  * ordered
   298    Start (or stop) each clone only after the operation on the previous clone completed.
   300  * interleaved
   301    If a colocation constraint is created between two clone resources and interleaved is true, then clone N from one resource will be assigned the same location as clone N from the other resource.
   302    If the number of runnable clones differs, then the leftovers can be located anywhere.
   303 Using a cloned group is a much better way of achieving the same result.
   305  * notify
   306    If true, inform peers before and after any clone is stopped or started.
   307    If an action failed, you will (currently) not recieve a post-notification.
   308    Instead you can next expect to see a pre-notification for a stop.
   309    If a stop fails, and you have fencing you will get a post-notification for the stop after the fencing operation has completed.
   310    In order to use the notification service ALL decendants of the clone MUST support the notify action.
   311    Currently this action is not permitted to fail, though depending on your configuration, can block almost indefinitly.
   312    Behaviour in response to a failed action or notificaiton is likely to be improved in future releases.
   314    See http://linux-ha.org/v2/Concepts/Clones for more information on notify actions
   317 NOTE: Clones must contain exactly one primitive or one group resource. 
   318       The CRM will complain about your configuration if this criteria is not met.
   319       Please use crm_verify to ensure your configuration is valid.
   320       The DTD is written this way to be order in-sensitive.
   321 -->
   323 <!ELEMENT clone (meta_attributes|instance_attributes|primitive|group)*>
   324 <!ATTLIST clone
   325           id            CDATA               #REQUIRED
   326           description   CDATA               #IMPLIED
   328           is_managed            CDATA                         #IMPLIED
   329           restart_type          (ignore|restart)              'ignore'
   330           multiple_active       (stop_start|stop_only|block)  'stop_start'
   331           resource_stickiness   CDATA                         #IMPLIED
   333           notify                (true|yes|1|false|no|0)       'false'
   334           globally_unique       (true|yes|1|false|no|0)       'true'
   335           ordered               (true|yes|1|false|no|0)       'false'
   336           interleave            (true|yes|1|false|no|0)       'false'>
   337 <!--
   338 Master/Slave resources are a superset of Clones in that instances can also be in one of two states.
   339 The meaning of the states is specific to the resource.
   341 NOTE: master_slave must contain exactly one primitive resource OR one group resource.
   342       It may not contain both, nor may it contain neither.
   343       The CRM will complain about your configuration if this criteria is not met.
   344       Please use crm_verify to ensure your configuration is valid.
   345       The DTD is written this way to be order in-sensitive.
   346 -->
   347 <!ELEMENT master_slave (meta_attributes|instance_attributes|primitive|group)*>
   348 <!ATTLIST master_slave
   349           id            CDATA       #REQUIRED
   350           description   CDATA       #IMPLIED
   352           is_managed            CDATA                         #IMPLIED
   353           restart_type          (ignore|restart)              'ignore'
   354           multiple_active       (stop_start|stop_only|block)  'stop_start'
   355           resource_stickiness   CDATA                         #IMPLIED
   357           notify                (true|yes|1|false|no|0)       'false'
   358           globally_unique       (true|yes|1|false|no|0)       'true'
   359           ordered               (true|yes|1|false|no|0)       'false'
   360           interleave            (true|yes|1|false|no|0)       'false'>
   362 <!--
   363 Most resource options are configured as instance attributes.
   364 Some of the built-in options can be configured directly on the resource or as an instance attribute.
   365 The advantage of using instance attributes is the added flexibility that can be achieved through conditional ?<rule/>s (see below).
   367 You can have multiple sets of 'instance attributes', they are first sorted by score and then processed.
   368 The first to have its ?<rule/> satisfied and define an attribute wins.
   369 Subsequent values for the attribute will be ignored.
   371 Note that:
   372  * instance_attributes sets with id equal to cib-bootstrap-options are treated as if they have a score of INFINITY.
   373  * instance_attributes sets with no score implicitly have a score of zero.
   374  * instance_attributes sets with no rule implicitly have a rule that evaluates to true.
   376 The addition of conditional <rule/>s to the instance_attributes object allows for an infinite variety of configurations.
   377 Just some of the possibilities are:
   378  * Specify different resource parameters
   379    * depending on the node it is allocated to (a resource may need to use eth1 on host1 but eth0 on host2)
   380    * depending on the time of day (run 10 web-servers at night an 100 during the day)
   381  * Allow nodes to have different attributes depending on the time-of-day
   382    * Set resource_stickiness to avoid failback during business hours but allow resources to be moved to a more preferred node on the weekend
   383    * Switch a node between a "front-end" processing group during the day to a "back-end" group at night.
   385 Common instance attributes for all resource types:
   386  * priority (integer, default=0):
   387    dictates the order in which resources will be processed.
   388    If there is an insufficient number of nodes to run all resources, the lower priority resources will be stopped to make sure the higher priority resources remain active.
   390  * is_managed: See previous description.
   392  * resource_stickiness: See previous description.
   394  * target_role: (Started|Stopped|Master|Slave|default, default=#default)
   395    * #default : Let the cluster decide what to do with the resource
   396    * Started : Ignore any specified value of is_managed or is_managed_default and attempt to start the resource
   397    * Stopped : Ignore any specified value of is_managed or is_managed_default and attempt to stop the resource
   398    * Master : Ignore any specified value of is_managed, is_managed_default or promotion preferences and attempt to put all instances of a cloned resource into Master mode.
   399    * Slave : Ignore any specified value of is_managed, is_managed_default or promotion preferences and attempt to put all instances of a cloned resource into Slave mode.
   401 Common instance attributes for clones:
   402  * clone_max (integer, default=1):
   403    the number of clones to be run
   405 * clone_node_max (integer, default=1):
   406   the maximum number of clones to be run on a single node
   408 Common instance attributes for nodes:
   409  * standby (boolean, default=FALSE)
   410    if TRUE, indicates that resources can not be run on the node
   411 -->
   412 <!ELEMENT instance_attributes (rule*, attributes)>
   413 <!ATTLIST instance_attributes
   414           id                CDATA        #REQUIRED
   415           score             CDATA        #IMPLIED>
   417 <!ELEMENT meta_attributes (rule*, attributes)>
   418 <!ATTLIST meta_attributes
   419           id                CDATA        #REQUIRED
   420           score             CDATA        #IMPLIED>
   422 <!--
   423 Every constraint entry also has a 'lifetime' attribute, which expresses when this constraint is applicable.
   424 For example, a constraint may only be valid during certain times of the day, or days of the week.
   425 Eventually, we would like to be able to support constraints that only last until events such as the next reboot or the next transition.
   426 -->
   427 <!ELEMENT constraints (rsc_order|rsc_colocation|rsc_location)*>
   429 <!--
   430 rsc_ordering constraints express dependencies between the actions on two resources.
   431  * from : A resource id
   432  * action : What action does this constraint apply to.
   433  * type : Should the action on from occur before or after action on to
   434  * to : A resource id
   435  * symmetrical : If TRUE, create the reverse constraint for the other action also.
   437 Read as:
   438      action from type to_action to
   439 eg. 
   440      start rsc1 after promote rsc2
   442 -->
   443 <!ELEMENT rsc_order (lifetime?)>
   444 <!ATTLIST rsc_order
   445           id        CDATA #REQUIRED
   446           from      CDATA #REQUIRED
   447           to        CDATA #REQUIRED
   448           action    CDATA		'start'
   449           to_action CDATA		'start'
   450           type      (before|after)	'after'
   451           score     CDATA		'INFINITY'
   452           symmetrical (true|yes|1|false|no|0)	'true'>
   454 <!--
   456 Specify where a resource should run relative to another resource
   458 Make rsc 'from' run on the same machine as rsc 'to'
   460 If rsc 'to' cannot run anywhere and 'score' is INFINITY, 
   461   then rsc 'from' wont be allowed to run anywhere either
   462 If rsc 'from' cannot run anywhere, then 'to' wont be affected
   464 -->
   465 <!ELEMENT rsc_colocation (lifetime?)>
   466 <!ATTLIST rsc_colocation
   467           id             CDATA #REQUIRED
   468           from           CDATA #REQUIRED
   469           from_role      CDATA #IMPLIED
   470           to             CDATA #REQUIRED
   471           to_role        CDATA #IMPLIED
   472           symmetrical    (true|yes|1|false|no|0)	'false'
   473           node_attribute CDATA #IMPLIED
   474           score          CDATA #REQUIRED>
   476 <!--
   477 Specify which nodes are eligible for running a given resource.
   479 During processing, all rsc_location for a given rsc are evaluated.
   481 All nodes start out with their base weight (which defaults to zero).
   482 This can then be modified (up or down) using any number of rsc_location constraints.
   484 Then the highest non-zero available node is determined to place the resource.
   485 If multiple nodes have the same weighting, the node with the fewest running resources is chosen.
   487 The rsc field is, surprisingly, a resource id.
   488 -->
   489 <!ELEMENT rsc_location (lifetime?,rule*)>
   490 <!ATTLIST rsc_location
   491           id          CDATA #REQUIRED
   492           description CDATA #IMPLIED
   493           rsc         CDATA #REQUIRED
   494           node        CDATA #IMPLIED
   495           score       CDATA #IMPLIED>
   496 <!ELEMENT lifetime (rule+)>
   497 <!ATTLIST lifetime id  CDATA     #REQUIRED>
   499 <!--
   500  * boolean_op
   501    determines how the results of multiple expressions are combined.
   503  * role
   504    limits this rule to applying to Multi State resources with the named role.
   505    Roles include Started, Stopped, Slave, Master though only the last two are considered useful.
   506    NOTE: A rule with role="Master" can not determin the initial location of a clone instance.
   507    It will only affect which of the active instances will be promoted.
   509  * score
   510    adjusts the preference for running on the matched nodes.
   511    NOTE: Nodes that end up with a negative score will never run the resource.
   512    Two special values of "score" exist: INFINITY and -INFINITY.
   513    Processing of these special values is as follows:
   515       INFINITY +/- -INFINITY : -INFINITY
   516       INFINITY +/-  int      :  INFINITY
   517      -INFINITY +/-  int      : -INFINITY
   519  * score_attribute 
   520    an alternative to the score attribute that provides extra flexibility.
   521   Each node matched by the rule has its score adjusted differently, according to its value for the named node attribute.
   522   Thus in the example below, if score_attribute="installed_ram" and nodeA would have its preference to run "the resource" increased by 1024 whereas nodeB would have its preference increased only by half as much.
   524     <nodes>
   525       <node id="uuid1" uname="nodeA" type="normal">
   526         <instance_attributes id="uuid1:custom_attrs">
   527           <attributes>
   528             <nvpair id="uuid1:installed_ram" name="installed_ram" value="1024"/>
   529             <nvpair id="uuid1:my_other_attr" name="my_other_attr" value="bob"/>
   530           </attributes>
   531         </instance_attributes>
   532       </node>
   533       <node id="uuid2" uname="nodeB" type="normal">
   534         <instance_attributes id="uuid2:custom_attrs">
   535           <attributes>
   536             <nvpair id="uuid2:installed_ram" name="installed_ram" value="512"/>
   537           </attributes>
   538         </instance_attributes>
   539       </node>
   540     </nodes>
   541 -->
   542 <!ELEMENT rule (expression|date_expression|rule)*>
   543 <!ATTLIST rule
   544           id                  CDATA          #REQUIRED
   545           role                CDATA          #IMPLIED
   546           score               CDATA          #IMPLIED
   547           score_attribute     CDATA          #IMPLIED
   548           boolean_op          (or|and)      'and'>
   550 <!--
   551 Returns TRUE or FALSE depending on the properties of the object being tested.
   553  * type determines how the values being tested.
   554    * integer Values are converted to floats before being compared.
   555    * version The "version" type is intended to solve the problem of comparing 1.2 and 1.10
   556    * string Uses strcmp
   558 Two built-in attributes are node id #id and node uname #uname so that:
   559       attribute=#id value=8C05CA5C-C9E3-11D8-BEE6-000A95B71D78 operation=eq, and
   560       attribute=#uname value=test1 operation=eq
   561 would both be valid tests.
   563 An extra built-in attribute called #is_dc will be set to true or false depending on whether the node is operating as the DC for the cluster.
   564 Valid tests using this test would be of the form:
   566         attribute=#is_dc operation=eq value=true,  and
   567         attribute=#is_dc operation=eq value=false, and
   568         attribute=#is_dc operation=ne value=false
   569                         (for those liking double negatives :))
   570 -->
   571 <!ELEMENT expression EMPTY>
   572 <!ATTLIST expression
   573           id         CDATA                    #REQUIRED
   574           attribute  CDATA                    #REQUIRED
   575           operation  (lt|gt|lte|gte|eq|ne|defined|not_defined) #REQUIRED
   576           value      CDATA                    #IMPLIED
   577           type       (number|string|version) 'string'>
   579 <!--
   580  * start : A date-time conforming to the ISO8601 specification.
   581  * end : A date-time conforming to the ISO8601 specification.
   582    A value for end may, for any usage, be omitted and instead inferred using start and duration.
   583  * operation
   584    * gt : Compares the current date-time with start date.
   585      Checks now > start.
   586    * lt : Compares the current date-time with end date.
   587      Checks end > now
   588    * in_range : Compares the current date-time with start and end.
   589      Checks now > start and end > now.
   590      If either start or end is omitted, then that part of the comparision is not performed.
   591    * date_spec : Performs a cron-like comparision between the contents of date_spec and now.
   592      If values for start and/or end are included, now must also be within that range.
   593      Or in other words, the date_spec operation can also be made to perform an extra in_range check.
   595 NOTE: Because the comparisions (except for date_spec) include the time, the eq, neq, gte and lte operators have not been implemented.
   596 -->
   597 <!ELEMENT date_expression (date_spec?,duration?)>
   598 <!ATTLIST date_expression
   599         id         CDATA  #REQUIRED
   600         operation  (in_range|date_spec|gt|lt) 'in_range'
   601         start      CDATA  #IMPLIED
   602         end        CDATA  #IMPLIED>
   604 <!--
   605 date_spec is used for (surprisingly  ) date_spec operations.
   607 Fields that are not supplied are ignored.
   609 Fields can contain a single number or a single range.
   610 Eg.
   611 monthdays="1" (Matches the first day of every month) and hours="09-17" (Matches hours between 9am and 5pm inclusive) are both valid values.
   612 weekdays="1,2" and weekdays="1-2,5-6" are NOT valid ranges.
   613 This may change in a future release.
   615  * seconds : Value range 0-59
   616  * minutes : Value range 0-59
   617  * hours : Value range 0-23
   618  * monthdays : Value range 0-31 (depending on current month and year)
   619  * weekdays : Value range 1-7 (1=Monday, 7=Sunday)
   620  * yeardays : Value range 1-366 (depending on current year)
   621  * months : Value range 1-12
   622  * weeks : Value range 1-53 (depending on weekyear)
   623  * weekyears : Value range 0...
   624   (NOTE: weekyears may differ from Gregorian years.
   625   Eg. 2005-001 Ordinal == 2005-01-01 Gregorian == 2004-W53-6 Weekly )
   626  * years : Value range 0...
   627  * moon : Value range 0..7 - 0 is new, 4 is full moon.
   628    Because we can(tm)
   629 -->
   631 <!ELEMENT date_spec EMPTY>
   632 <!ATTLIST date_spec
   633         id         CDATA  #REQUIRED
   634         hours      CDATA  #IMPLIED
   635         monthdays  CDATA  #IMPLIED
   636         weekdays   CDATA  #IMPLIED
   637         yeardays   CDATA  #IMPLIED
   638         months     CDATA  #IMPLIED
   639         weeks      CDATA  #IMPLIED
   640         weekyears  CDATA  #IMPLIED
   641         years      CDATA  #IMPLIED
   642         moon       CDATA  #IMPLIED>
   644 <!--
   645 duration is optionally used for calculating a value for end.
   646 Any field not supplied is assumed to be zero and ignored.
   647 Negative values might work.
   648 Eg. months=11 should be equivalent to writing years=1, months=-1 but is not encouraged.
   649 -->
   650 <!ELEMENT duration EMPTY>
   651 <!ATTLIST duration
   652         id         CDATA  #REQUIRED
   653         hours      CDATA  #IMPLIED
   654         monthdays  CDATA  #IMPLIED
   655         weekdays   CDATA  #IMPLIED
   656         yeardays   CDATA  #IMPLIED
   657         months     CDATA  #IMPLIED
   658         weeks      CDATA  #IMPLIED
   659         years      CDATA  #IMPLIED>
   660 <!--
   661 Example 1: True if now is any time in the year 2005.
   663 <rule id="rule1">
   664   <date_expression id="date_expr1" start="2005-001" operation="in_range">
   665     <duration years="1"/>
   666   </date_expression>
   667 </rule>
   668 Example 2: Equivalent expression.
   670 <rule id="rule2">
   671   <date_expression id="date_expr2" operation="date_spec">
   672     <date_spec years="2005"/>
   673   </date_expression>
   674 </rule>
   675 Example 3: 9am-5pm, Mon-Friday
   677 <rule id="rule3">
   678   <date_expression id="date_expr3" operation="date_spec">
   679     <date_spec hours="9-16" days="1-5"/>
   680   </date_expression>
   681 </rule>
   682 Example 4: 9am-5pm, Mon-Friday, or all day saturday
   684 <rule id="rule4" boolean_op="or">
   685   <date_expression id="date_expr4-1" operation="date_spec">
   686     <date_spec hours="9-16" days="1-5"/>
   687   </date_expression>
   688   <date_expression id="date_expr4-2" operation="date_spec">
   689     <date_spec days="6"/>
   690   </date_expression>
   691 </rule>
   692 Example 5: 9am-5pm or 9pm-12pm, Mon-Friday
   694 <rule id="rule5" boolean_op="and">
   695   <rule id="rule5-nested1" boolean_op="or">
   696     <date_expression id="date_expr5-1" operation="date_spec">
   697       <date_spec hours="9-16"/>
   698     </date_expression>
   699     <date_expression id="date_expr5-2" operation="date_spec">
   700       <date_spec hours="21-23"/>
   701     </date_expression>
   702   </rule>
   703   <date_expression id="date_expr5-3" operation="date_spec">
   704     <date_spec days="1-5"/>
   705   </date_expression>
   706 </rule>
   707 Example 6: Mondays in March 2005
   709 <rule id="rule6" boolean_op="and">
   710   <date_expression id="date_expr6" operation="date_spec" start="2005-03-01" end="2005-04-01">
   711     <date_spec weekdays="1"/>
   712   </date_expression>
   713 </rule>
   714 NOTE: Because no time is specified, 00:00:00 is implied.
   715 This means that the range includes all of 2005-03-01 but none of 2005-04-01.
   716 You may wish to write end="2005-03-31T23:59:59" to avoid confusion.
   718 Example 7: Friday the 13th if it is a full moon
   720 <rule id="rule7" boolean_op="and">
   721   <date_expression id="date_expr7" operation="date_spec">
   722     <date_spec weekdays="5" monthdays="13" moon="4"/>
   723   </date_expression>
   724 </rule>
   725 -->
   727 <!--
   728 You don't have to give a value.
   729 There's a difference between a key not being present and a key not having a value.
   730 -->
   731 <!ELEMENT nvpair EMPTY>
   732 <!ATTLIST nvpair
   733           id     CDATA  #REQUIRED
   734           name   CDATA  #REQUIRED
   735           value  CDATA  #IMPLIED>
   737 <!ELEMENT attributes (nvpair*)>
   739 <!--
   740 These attributes take effect only if no value has previously been applied as part of the node's definition.
   741 Additionally, when the node reboots all settings made here are erased.
   743 id must be the UUID of the node.
   744 -->
   745 <!ELEMENT transient_attributes (instance_attributes*)>
   746 <!ATTLIST transient_attributes id CDATA #IMPLIED>
   748 <!--=========== Status - Advanced Use Only ===========-->
   750 <!--
   751 Details about the status of each node configured.
   753 HERE BE DRAGONS
   755 Never, ever edit this section directly or using cibadmin.
   756 The consequences of doing so are many and varied but rarely ever good or what you anticipated.
   757 To discourage this, the status section is no longer even written to disk, and is always discarded at startup.
   759 To avoid duplication of data, state entries only carry references to nodes and resources.
   760 -->
   761 <!ELEMENT status (node_state*)>
   763 <!--
   764 The state of a given node.
   766 This information is updated by the DC based on inputs from sources such as the CCM, status messages from remote LRMs and requests from other nodes.
   767  * id       -  is the node's UUID.
   768  * uname    - is the result of uname -n for the node.
   769  * crmd     - records whether the crmd process is running on the node
   770  * in_ccm   - records whether the node is part of our membership partition
   771  * join     - is the node's membership status with the current DC.
   772  * expected - is the DC's expectation of whether the node is up or not.
   773  * shutdown - is set to the time at which the node last asked to be shut down
   775 Ideally, there should be a node_state entry for every entry in the <nodes> list.
   777 -->
   778 <!ELEMENT node_state (transient_attributes|lrm)*>
   779 <!ATTLIST node_state
   780         id              CDATA                   #REQUIRED
   781         uname           CDATA                   #REQUIRED
   782         ha              (active|dead)           #IMPLIED
   783         crmd            (online|offline)        'offline'
   784         join            (pending|member|down)   'down'
   785         expected        (pending|member|down)   'down'
   786         in_ccm          (true|yes|1|false|no|0) 'false'
   787         crm-debug-origin CDATA                  #IMPLIED
   788         shutdown        CDATA                   #IMPLIED
   789         clear_shutdown  CDATA                   #IMPLIED>
   791 <!--
   792 Information from the Local Resource Manager of the node.
   793 It contains a list of all resource's added (but not necessarily still active) on the node.
   794 -->
   795 <!ELEMENT lrm (lrm_resources)>
   796 <!ATTLIST lrm id CDATA #REQUIRED>
   798 <!ELEMENT lrm_resources (lrm_resource*)>
   799 <!ELEMENT lrm_resource (lrm_rsc_op*)>
   800 <!ATTLIST lrm_resource
   801           id            CDATA #REQUIRED
   802           class             (lsb|ocf|heartbeat|stonith) #REQUIRED
   803           type              CDATA        #REQUIRED
   804           provider          CDATA        #IMPLIED>
   805 <!--
   806 lrm_rsc_op (Resource Status)
   808 id: Set to [operation] +"_"+ [operation] +"_"+ [an_interval_in_milliseconds]
   810 operation typically start, stop, or monitor
   812 call_id: Supplied by the LRM, determins the order of in which lrm_rsc_op objects should be processed in order to determin the resource's true state
   814 rc_code is the last return code from the resource
   816 rsc_state is the state of the resource after the action completed and should be used as a guide only.
   818 transition_key contains an identifier and seqence number for the transition.
   820 At startup, the TEngine registers the identifier and starts the sequence at zero.
   821 It is used to identify the source of resource actions.
   823 transition_magic contains an identifier containing call_id, rc_code, and {{transition_key}}}.
   825 As the name suggests, it is a piece of magic that allows the TE to always identify the action from the stream of xml-diffs it subscribes to from the CIB.
   827 last_run       ::= when did the op run (as age)
   828 last_rc_change ::= last rc change (as age)
   829 exec_time      ::= time it took the op to run
   830 queue_time     ::= time spent in queue
   832 op_status is supplied by the LRM and conforms to this enum:
   834 typedef enum {
   835         LRM_OP_PENDING = -1,
   836         LRM_OP_DONE,
   837         LRM_OP_CANCELLED,
   838         LRM_OP_TIMEOUT,
   839         LRM_OP_NOTSUPPORTED,
   840         LRM_OP_ERROR,
   841 } op_status_t;
   842 The parameters section allows us to detect when a resource's definition has changed and the needs to be restarted (so the changes take effect).
   843 -->
   844 <!ELEMENT lrm_rsc_op EMPTY>
   845 <!ATTLIST lrm_rsc_op
   846           id                    CDATA #REQUIRED
   847           operation             CDATA #REQUIRED
   848           op_status             CDATA #REQUIRED
   849           rc_code               CDATA #REQUIRED
   850           call_id               CDATA #REQUIRED
   851           crm_feature_set       CDATA #REQUIRED
   852           crm-debug-origin      CDATA #IMPLIED
   853           migrate_from          CDATA #IMPLIED
   854           transition_key        CDATA #IMPLIED
   855           op_digest             CDATA #IMPLIED
   856           op_restart_digest     CDATA #IMPLIED
   857           op_force_restart      CDATA #IMPLIED
   859           last_run              CDATA #IMPLIED
   860           last_rc_change        CDATA #IMPLIED
   861           exec_time             CDATA #IMPLIED
   862           queue_time            CDATA #IMPLIED
   864           interval              CDATA #REQUIRED
   865           transition_magic      CDATA #REQUIRED>

mercurial