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

[kgaillot 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.

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.
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.
-- 
Ken Gaillot <kgaillot at redhat.com>