[ClusterLabs] Q: Recommened directory for RA auxillary files?

[Jan Pokorný]

On 02/09/19 15:23 +0200, Ulrich Windl wrote:
> Are there any recommendations where to place (fixed content) files
> an RA uses?
> Usually my RAs use a separate XML file for the metadata, just to
> allow editing it in XML mode automatically.  Traditionally I put the
> file in the same directory as the RA itself (like "cat $0.xml" for
> meta-data).  Are there any expectations that every file in the RA
> directory is an RA?

Pacemaker itself only scans the relevant directories (in OCF
context, subdirectories of $OCF_ROOT/resource.d dedicated to particular
resource agent providers; note $OCF_ROOT boils down to /usr/lib/ocf in
this case), and will initially exclude any file that is not executable
(for at least one level of standard Unix permissions) or those
starting with a dot (~pseudo-hidden in Unix tradition).

This should provide some hints regarding possible co-location within
the same directory, at least when only pacemaker is considered as the
discoverer/exerciser/manager of the agents.

You (like anyone else) have the opportunity to get any presumably
pacemaker-implementation-non-contradicting conventions burnt even
firmer into the future revision of OCF, taking

https://github.com/ClusterLabs/OCF-spec/blob/master/ra/next/resource-agent-api.md#the-resource-agent-directory

as a starting point.  This would preempt portability glitches should
there be anything else than pacemaker to run your agents.

(E.g., there could be parallel implementations that would only
require the actual executability, e.g. as assigned with filesystem
backed extended access control, or a relaxed resource runner that
makes do just with a non-executable file with a legitimately looking
shebang like Perl does.)

> (Currently I'm extending an RA, and I'd like to provide some
> additional user-modifiable template file, and I wonder which path to
> use)

Intuitively, I would toy with and idea akin to 
/etc/ocf/conf.d/PROVIDER/AGENT.EXT scheme.  Similarly
/etc/ocf/conf-local.d/PROVIDER/AGENT.EXT for localhost
only override, see below.

Also, for as homogenous environment across the nodes as possible (and
if possible), synchronizing everything but notable exceptions such as
/etc/passwd, /etc/shadow/, /etc/group, /etc/hostname, /etc/cron.* and
similar asymmetry-wanted configurations from /etc hierarchy sounds
like a good idea.  Off the top of my head, csync2 with its hooks
system serves exactly this purpose, but there are likely more
that could fill the bill.

-- 
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/20190902/7c612436/attachment.sig>