>>> Ken Gaillot <[email protected]> schrieb am 04.09.2019 um 16:26 in Nachricht <[email protected]>: > 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 <[email protected]> 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". 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... Regards, Ulrich > ‑‑ > Ken Gaillot <[email protected]> > > _______________________________________________ > Manage your subscription: > https://lists.clusterlabs.org/mailman/listinfo/users > > ClusterLabs home: https://www.clusterlabs.org/ _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
