Resource Templates
==================  
Dejan_Muhamedagic_dejan@suse.de_,_Tanja_Roth_taroth@suse.de_,_Thomas_Schraitle_toms@suse.de_,_Yan_Gao_ygao@suse.com
V1.0, February 2012

== Abstract ==

If you want to create lots of resources with similar configurations, defining a 
resource template simplifies the task. Once defined, it can be referenced in 
primitives or in certain types of constraints.

   
== Configuring Resources with Templates ==

The primitives referencing the template will inherit all meta 
attributes, instance attributes, utilization attributes and operations defined 
in the template. And you can define specific attributes and operations for any 
of the primitives. If any of these are defined in both the template and the 
primitive, the values defined in the primitive will take precedence over the 
ones defined in the template. 

Hence, resource templates help to reduce the amount of configuration work. 
If any changes are needed, they can be done to the template definition and 
will take effect globally in all resource definitions referencing that
template.

Resource templates have a similar syntax like primitives. For example:

[source,Bash]
----
rsc_template vm-template ocf:heartbeat:Xen \
        meta allow-migrate="true" \
        utilization memory="512" \
        op monitor interval="15s" timeout="60s" \
        op start interval="0" timeout="60s
----

Once you defined the new resource template, you can use it in primitives:

[source,Bash]
----
primitive vm1 @vm-template \
        params name="vm1" xmfile="/etc/xen/shared-vm/vm1"
----
    
The new primitive `vm1` is going to inherit everything from the `vm-template`. For 
example, the equivalent of the above two would be:

[source,Bash]
----
primitive vm1 ocf:heartbeat:Xen \
        meta allow-migrate="true" \
        utilization memory="512" \
        op monitor interval="15s" timeout="60s" \
        op start interval="0" timeout="60s \
        params name="vm1" xmfile="/etc/xen/shared-vm/vm1"
----
    
If you want to overwrite some attributes or operations, add them to the 
particular primitive's definition. 

For instance, the following new primitive `vm2` has special 
attribute values. Its `monitor` operation has a longer `timeout` and `interval`, and 
the primitive has an additional `stop` operation.

[source,Bash]
----
primitive vm2 @vm-template \
        meta allow-migrate="false" \
        utilization memory="1024" \
        params name="vm2" xmfile="/etc/xen/shared-vm/vm2" \
        op monitor interval="30s" timeout="120s" \
        op stop interval="0" timeout="60s"    
----
    
The following command shows the resulting definition of a resource in XML:
    
[source,Bash]
----
# crm_resource --query-xml --resource vm2
----
    
The following command shows its raw definition in cib:
    
[source,Bash]
----
# crm_resource --query-xml-raw --resource vm2
----

== Referencing Templates in Constraints ==
   
A resource template can be referenced in the following types of constraints:

- `order` constraints
- `colocation` constraints,
- `rsc_ticket` constraints (for multi-site clusters).

Resource templates referenced in constraints stand for all primitives which are 
derived from that template. This means, the constraint applies to all primitive 
resources referencing the resource template. Referencing resource templates in 
constraints is an alternative to resource sets and can simplify the cluster 
configuration considerably.

For example:

[source,Bash]
----
colocation vm-template-colo-base-rsc inf: vm-template base-rsc
----

is the equivalent of the following constraint configuration:

[source,Bash]
----
colocation vm-colo-base-rsc inf: ( vm1 vm2 ) base-rsc
----

[NOTE]
======
In a colocation constraint, only one template may be referenced, and the
other reference must be a regular resource.
======

Resource templates can also be referenced in resource sets.

For example:

[source,Bash]
----
order order1 inf: base-rsc vm-template top-rsc
----

is the equivalent of the following constraint configuration:

[source,Bash]
----
order order1 inf: base-rsc vm1 vm2 top-rsc
----

If the resources referencing the template can run in parallel:

[source,Bash]
----
order order2 inf: base-rsc ( vm-template ) top-rsc
----

is the equivalent of the following constraint configuration:

[source,Bash]
----
order order2 inf: base-rsc ( vm1 vm2 ) top-rsc
----