On Wed, 2005-06-08 at 15:39 -0400, Coman Iliut wrote:
> Is there any documentation you can point me to, for rgmanager?
>
> I installed the rpm but there anre no man pages.
Doxygen!
(just kidding)
Not really, there's a UI you can use to configure it (system-config-
cluster), or you can refer to the examples/*.conf and
src/daemons/tests/*.conf.
I'm still working on a decent "HOWTO" for people who wish to hand-
edit... I'm about 2% done, but here it is anyway... ;)
-- Lon
rgmanager HOWTO, v0.0.1
How Resources Work
Resource Agents, Meta-Data, and an overview
Resource information is provided to rgmanager via the "meta-data"
command-line option. This option tells the user (or program, in this
case) what the various parameters are for a given resource type. For
example, the output of the "ip.sh" looks something like the following
(the description tags have been removed to make this shorter):
<?xml version="1.0" ?>
<resource-agent version="rgmanager 2.0" name="ip">
<version>1.0</version>
<parameters>
<parameter name="address" unique="1" primary="1"/>
<parameter name="family"/>
<parameter name="monitor_link">
<content type="boolean" default="1"/>
</parameter>
</parameters>
<actions>
<action name="start" timeout="20"/>
<action name="stop" timeout="20"/>
<action name="status" interval="20" timeout="10"/>
<action name="monitor" interval="20" timeout="10"/>
<action name="status" depth="10" interval="60" timeout="20"/>
<action name="monitor" depth="10" interval="60" timeout="20"/>
<action name="status" depth="20" interval="2m" timeout="20"/>
<action name="monitor" depth="20" interval="2m" timeout="20"/>
<action name="meta-data" timeout="20"/>
<action name="verify-all" timeout="20"/>
</actions>
<special tag="rgmanager">
<attributes maxinstances="1"/>
</special>
</resource-agent>
For each <parameter> block, rgmanager will call the script with an
OCF_RESKEY_param environment variable the parameter exists. We'll get
back to that later.
This is closely related to the OCF RA API 1.0, but there are a few
differences of note: we allow "primary", "required", and "unique"
attributes. "Primary" parameters and "unique" parameters can not be
shared between any two resources of the same type in
/etc/cluster/cluster.conf, and a resource must have all "required"
parameters. "Primary" means that it is unique, required, and can be
passed by reference in the resource tree, for instance:
<rm>
<resources>
<ip address="192.168.1.2" monitor_link="1"/>
</resources>
<service name="foo">
<ip ref="192.168.1.2"/>
</service>
</rm>
Note, however, the <attributes maxinstances="1"> in the <special> tag.
This means that the IP address may only appear once in the entire
service tree; it may not be reused. A subsequent reference to
192.168.1.2 will be completely ignored by rgmanager. If there is no
"maxinstances" tag in the resource agent meta-data, there is no limit on
the maximum number of times the resource may be referenced.
Remember when I mentioned that parameters are passed as environment
variables to the resource scripts? In normal terms, here's how
rgmanager starts an IP address given the above parameters:
OCF_RESKEY_address="192.168.1.2" \
OCF_RESKEY_monitor_link="1" \
/usr/share/cluster/ip.sh start
Global vs. Inline Resources and the Resource Dependency Tree
Resources declared "inline" (or "private resources"), however, may
*NEVER* be reused. A resource is "global" if it is declared in the
<resources> block. A resource is "inline" if it is only assigned
attributes in the context of a service. In our previous example,
192.168.1.2 was a global resource. In the following example,
192.168.1.2 is an inline (or private) resource:
<rm>
<resources/>
<service name="foo">
<ip address="192.168.1.2" monitor_link="1"/>
</service>
</rm>
As stated previously, the "primary" attribute for a resource must be
unique across resource types. So, the following is illegal (the second
instance of 192.168.1.2 will be ignored):
<rm>
<resources/>
<service name="foo">
<ip address="192.168.1.2" monitor_link="1"/>
</service>
<service name="bar">
<ip address="192.168.1.2" monitor_link="1"/>
</service>
</rm>
Resources may depend on other resources. What we mean here is that a
user may have a resource "y" depend on resource "x". The rules are as
follows:
* A resource "y" is dependent on resource "x" if it is a descendent of
resource "y" in the tree.
* Resources must be started before dependent children may start.
* Resources must remain running until all dependent children are
stopped.
Here's a secret to help you remember: <service> is a resource, too. We
just mask the ability to create it in the <resources> block of
cluster.conf (to eliminate confusion). So, in order for a service to
be started/healthy, all of its parts must also be started/healthy.
--
Linux-cluster@xxxxxxxxxx
http://www.redhat.com/mailman/listinfo/linux-cluster
