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)
pgpxCBlh8emSE.pgp
Description: PGP signature
_______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/