[ClusterLabs] [rgmanager] generic 'initscript' resource agent that passes arguments?

[Jan Pokorný]

On 13/09/16 17:33 -0400, bergman at merctech.com wrote:
> In the message dated: Tue, 06 Sep 2016 20:36:53 +0200,
> The pithy ruminations from Jan =?utf-8?Q?Pokorn=C3=BD?= on 
> <Re: [ClusterLabs] [rgmanager] generic 'initscript' resource agent that passes arguments?> were:
> 
> => On 29/08/16 13:41 -0400, bergman at merctech.com wrote:
> => > I've got a number of scripts that are based on LSB compliant scripts,
> => > but which also accept arguments & values. For example, a script to manage
> => > multiple virtual machines has a command-line in the form:
> => > 
> => > 	vbox_init --vmname $VMNAME [-d|--debug] [start|stop|status|restart]
> => > 
> 
> [SNIP!]
> 
> => 
> => 
> => Adapting script.sh to scriptArgs.sh working as desired should not
> => be a hard task, though.  Once you add such custom RA to the system
> => (i.e., across all nodes), supposing you have adapted produced
> 
> OK.
> 
> Will ccs look for resource scripts anywhere other than
> "/usr/share/cluster"? Does it use a search path, such as:
> 
> 	/usr/share/cluster:/usr/local/share/cluster

What really matters is where rgmanager search for the agents, and there's
just a single, hardcoded path:

$ MANWIDTH=76 man rgmanager | col -b \
  | sed -n '/^RESOURCE AGENTS$/{:a;/^SERVICES/d;p;n;ba}'
> RESOURCE AGENTS
>        Resource agents define resource classes rgmanager can manage.
>        Rgmanager follows the Open Cluster Framework  Resource  Agent
>        API  v1.0  (draft)  standard,  with the following two notable
>        exceptions:
>
>         * Rgmanager does not call monitor; it only calls status
>         * Rgmanager looks for resource agets in /usr/share/cluster
                                                  ^^^^^^^^^^^^^^^^^^
>
>        Rgmanager uses the metadata from resource agents to determine
>        what  parameters  to  look  for  in  cluster.conf  for a each
>        resource type.  Viewing the resource agent  metadata  is  the
>        best way to understand all the various resource agent parame-
>        ters.

Note that ccs doesn't inspect that path at all; the only guard here is
that the configured resource agent is recognized in the cluster schema
and for this to be true, ccs_update_schema has to be invoked on adding
a new agent (as mentioned) and that script also relies solely on the
same path as rgmanager does -> the agent cannot be added anywhere else.

> or is there a way to specify alternative locations for local resource
> files?

Unfortunately not.  The best you can get is to have the agents live
somewhere else while being symlinked from the canonical path.

> I truly hate putting local files in directories that are managed by
> external packages -- it will surely be a source of future confusion and
> management difficulty.

They are not that managed -- your files should be neither overwritten nor
removed at any point in the cluster live-cycle, and you could identify
your "overlay" through the suggested symlink schema.

On the contrary, pacemaker offers great deal of flexibility on where to
search for the agents with its hierarchical approach so I would advise
to consider switching over if that would not be much of a hassle for
you (there's a clufter utility to ease the such a transition, which
I happen to maintain + the script would like require some slight
modifications like adding support for "monitor" action)

> => meta-data respectively, you should remember to run "ccs_update_schema"
> => so that any subsequent start of the cluster stack on the node or
> => modification via ccs utility will not fail due to unrecognized RA
> => if present in the to-apply configuration.
> 
> Got it.
> 
> => 
> => Note that the new agent will not get reflected in luci web UI
> => automatically, you would have to add a support on your own.
> => 
> 
> No problem, I do most cluster configuration via the command line.

It's straightforward, then.

-- 
Jan (Poki)
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 819 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/users/attachments/20160916/3f97ab5b/attachment-0004.sig>