[ClusterLabs] Antw: [EXT] Coming in Pacemaker 2.1.0: OCF resource agent path

[kgaillot at redhat.com]

On Thu, 2021-05-20 at 08:10 +0200, Ulrich Windl wrote:
> > > > <kgaillot at redhat.com> schrieb am 19.05.2021 um 23:33 in
> > > > Nachricht
> 
> <34dfdacadc85a258661a9fcd81b39c153ad1cf02.camel at redhat.com>:
> > Hi all,
> > 
> > We squeezed one more feature into the Pacemaker 2.1.0 release for
> > rc2:
> > the ability to search multiple directories for OCF resource agents.
> > 
> > Previously, the OCF root (typically /usr/lib/ocf) could be
> > specified at
> > build time via ./configure ‑‑with‑ocfdir, and all resource agents
> > had
> > to be in the resource.d directory below that.
> > 
> > Now, the configure script will have three related options:
> > 
> > * ‑‑with‑ocfdir: This establishes the OCF_ROOT variable that is
> > passed
> > to resource agents, which is used to find the ocf‑shellfuncs
> > include
> > files.
> > 
> > * ‑‑with‑ocfrainstalldir: This specifies where the ocf:pacemaker
> > resource agents will be installed.
> > 
> > * ‑‑with‑ocfrapath: This is a colon‑separated path of directories
> > that
> > will be searched for OCF resource agents (like PATH for agents).
> > 
> > All default to values provided by the resource‑agents package, if
> > available. Otherwise, they default to the current behavior.
> > 
> > Example:
> > 
> > ./configure ‑‑with‑ocfdir=/usr/libexec/ocf \
> >   
> > 
> 
> ‑‑with‑ocfrapath=/usr/libexec/ocf/resource.d:/usr/lib/ocf/resource.d:
> /srv/ocf/
> > resource.d
> > 
> > The above will define the OCF_ROOT as /usr/libexec/ocf instead of
> > the
> > usual /usr/lib/ocf. The ocf:pacemaker agents will be installed in
> > /usr/libexec/ocf/resource.d (via default).
> > 
> > When a resource agent needs to be executed, Pacemaker will search
> > in
> > three locations: first, /usr/libexec/ocf/resource.d, and if not
> > found
> > there, /usr/lib/ocf/resource.d, and if not found in either
> > location,
> > /srv/ocf/resource.d.
> 
> And when the RA is executed, will the OCF_ROOT be adjusted (for the
> RA)?

No, agents use OCF_ROOT to find include files, and those are likely to
be available at only one location. A path for include files would be
possible but logically separate (think LD_LIBRARY_PATH vs PATH).

The original OCF standard put agents and includes together under
/usr/ocf (/usr/lib/ocf was a later nonstandard convention). That turned
out to be a mistake when distributions went in the direction of the
Filesystem Hierarchy Standard instead. OCF 1.1's multiple resource
directories lets distributions follow the FHS or their own conventions
as desired.

Surprisingly, FHS and distribution standards are silent on where shell
includes should be, and there isn't even a widespread convention. So,
those remain under OCF_ROOT, but a distribution is free to point
OCF_ROOT wherever desired.

> 
> > 
> > An example use case might be installing custom agents beneath /srv
> > to
> > keep them separate from OS‑provided agents. Or, agents installed in
> > various temporary directories for Continuous Integration (CI)
> > testing.
> 
> But OCF has "sub-namespaces" (considering OCF to be a namespace)
> already (like
> heartbeat and pacemaker).
> So one could add "test", "unstable", "whatever", ...

Correct, but they all had to be under a single directory. That can be
less than ideal in some cases.

Example: a user mounts /usr read-only with OS-provided binaries, and
keeps all local executables under /srv.

Or: a third-party application installs all of its libraries, binaries,
etc., under /opt, without wanting to touch /usr.

The immediate use case we had was Continuous Integration testing -- the
goal is to keep all installed artifacts for a component in a dedicated
tree for that component. So, resource-agents installs its agents
beneath one directory, and pacemaker installs its agents beneath
another.

> > Or, a third‑party provider installing agents beneath /opt.
> > 
> > In the 2.1.0 release, the path will be a build‑time option, for
> > simplicity. If there is demand, it should be possible to make it a
> > run‑
> > time option, but that would have some drawbacks, so we're currently
> > not
> > planning to.
> 
> Regards,
> Ulrich
-- 
Ken Gaillot <kgaillot at redhat.com>