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

[Ken Gaillot]

On Thu, 2019-09-05 at 07:57 +0200, Ulrich Windl wrote:
> > > > Ken Gaillot <kgaillot at redhat.com> schrieb am 04.09.2019 um
> > > > 16:26 in
> 
> Nachricht
> <2634f19382b90736bdfb80b9c84997111479d337.camel at redhat.com>:
> > On Wed, 2019‑09‑04 at 10:07 +0200, Jehan‑Guillaume de Rorthais
> > wrote:
> > > On Tue, 03 Sep 2019 09:35:39 ‑0500
> > > Ken Gaillot <kgaillot at redhat.com> wrote:
> > > 
> > > > On Mon, 2019‑09‑02 at 15:23 +0200, Ulrich Windl wrote:
> > > > > Hi!
> > > > > 
> > > > > 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?
> > > > > (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)
> > > > > 
> > > > > Regards,
> > > > > Ulrich  
> > > > 
> > > > I believe most (maybe even all modern?) deployments have both
> > > > lib
> > > > and
> > > > resource.d under /usr/lib/ocf. If you have a custom provider
> > > > for
> > > > the RA
> > > > under resource.d, it would make sense to use the same pattern
> > > > under
> > > > lib.
> > > 
> > > Shouldn't it be $OCF_FUNCTIONS_DIR?
> > 
> > Good point ‑‑ if the RA is using ocf‑shellfuncs, yes. $OCF_ROOT/lib
> > should be safe if the RA doesn't use ocf‑shellfuncs.
> > 
> > It's a weird situation; the OCF standard actually specifies
> > /usr/ocf,
> > but everyone implemented /usr/lib/ocf. I do plan to add a configure
> > option for it in pacemaker, but it shouldn't be changed unless you
> > can
> > make the same change in every other cluster component that needs
> > it.
> 
> The thing with $OCF_ROOT is: If $OCF_ROOT already contains "/lib", it
> looks
> off to add another "/lib".

It does look weird, but that's the convention in use today.

I hope we eventually get to the point where the .../lib and
.../resource.d locations are configure-time options, and distros can
choose whatever's consistent with their usual policies. For those that
follow the FHS, it might be something like /usr/lib/ocf or
/usr/share/ocf, and /usr/libexec/ocf.

However all cluster components installed on a host must be configured
the same locations, so that will require careful coordination. It's
easier to just keep using the current ones :)

> To me it looks as if it's time for an $OCF_LIB (which would be
> $OCF_ROOT if
> the latter is /usr/lib/ocf already, otherwise $OCF_ROOT/lib).
> Personally I
> think the /usr/<something> predates the
> [/usr][/share]]/lib/<something>.
> 
> > 
> > > Could this be generalized to RA for their
> > > own lib or permanent dependencies files?
> > 
> > The OCF standard specifies only the resource.d subdirectory, and
> > doesn't comment on adding others. lib/heartbeat is a common choice
> > for
> > the resource‑agents package shell includes (an older approach was
> > to
> > put them as dot files in resource.d/heartbeat, and there are often
> > symlinks at those locations for backward compatibility).
> > 
> > Since "heartbeat" is a resource agent provider name, and the
> > standard
> > specifies that agents go under resource.d/<provider‑name>, it does
> > make
> > sense that lib/<provider‑name> would be where RA files would go.
> 
> I wonder when we will be able to retire "heartbeat" ;-) If it's
> supposed to be
> of "vendor" type, maybe replace it with "clusterlabs" at some time...

Definitely, that's been the plan for a while, it's just another change
that will require coordination across multiple components.

The hope is that we can at some point wrap up the OCF 1.1 standard, and
then move forward some of the bigger changes. It's just hard to
prioritize that kind of work when there's a backlog of important stuff.

> 
> Regards,
> Ulrich
-- 
Ken Gaillot <kgaillot at redhat.com>