Re: [ClusterLabs] Antw: Re: Q: Recommened directory for RA auxillary files?
On Thu, 2019-09-05 at 07:57 +0200, Ulrich Windl wrote: > > > > Ken Gaillot schrieb am 04.09.2019 um > > > > 16:26 in > > Nachricht > <2634f19382b90736bdfb80b9c84997111479d337.ca...@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 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/ predates the > [/usr][/share]]/lib/. > > > > > > 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/, it does > > make > > sense that lib/ 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 ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Antw: Re: Q: Recommened directory for RA auxillary files?
>>> Ken Gaillot schrieb am 04.09.2019 um 16:26 in Nachricht <2634f19382b90736bdfb80b9c84997111479d337.ca...@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 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/ predates the [/usr][/share]]/lib/. > >> 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/, it does make > sense that lib/ 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 > > ___ > 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/
Re: [ClusterLabs] Antw: Re: Q: Recommened directory for RA auxillary files?
On Wed, 2019-09-04 at 10:09 +0200, Jehan-Guillaume de Rorthais wrote: > On Wed, 04 Sep 2019 07:54:50 +0200 > "Ulrich Windl" wrote: > > > > > > Ken Gaillot schrieb am 03.09.2019 um > > > > > 16:35 in > > > > Nachricht > > <979978d5a488aabd9ed4a941ff4eac60c271c84d.ca...@redhat.com>: > > > 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. > > > > So what concrete path are you suggesting? > > /usr/lib//? > > I would bet on /usr/lib/ocf/lib/ ? That was what I had in mind. Parallels "heartbeat" -- Ken Gaillot ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Antw: Re: Q: Recommened directory for RA auxillary files?
>>> Jehan-Guillaume de Rorthais schrieb am 04.09.2019 um
10:07 in
Nachricht <20190904100736.14c93f9e@firost>:
> On Tue, 03 Sep 2019 09:35:39 ‑0500
> Ken Gaillot 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? Could this be generalized to RA for
> their
> own lib or permanent dependencies files?
It all depends (a bit):
I'm adding logrotate support for my RA: As there will be multiple instances,
each using different log files, the RA creates a logrotate config file that
matches the configured instance upon "start" and removes it upon "stop". As I
did not want to use a built-in logrotate template, I put it in an external
file, letting the user customize it (a bit). Like maximum file size, frequency
of rotation, etc.
The current template looks like this:
# {__NOTE__}
{__LOGDIR__}/*.log {
rotate 2
nocreate
size 1M
#weekly
#olddir {__LOGDIR__}/old
missingok
postrotate
kill -HUP $(cat '{__PIDFILE__}')
endscript
delaycompress
#nocompress
}
And I wondered where to put such files. Currently I'm using
"/etc/ocf///logrotate.in" which gives me kind of clean namespace.
Regards,
Ulrich
> ___
> 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/
Re: [ClusterLabs] Antw: Re: Q: Recommened directory for RA auxillary files?
On Wed, 04 Sep 2019 07:54:50 +0200 "Ulrich Windl" wrote: > >>> Ken Gaillot schrieb am 03.09.2019 um 16:35 in > Nachricht > <979978d5a488aabd9ed4a941ff4eac60c271c84d.ca...@redhat.com>: > > 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. > > So what concrete path are you suggesting? /usr/lib//? I would bet on /usr/lib/ocf/lib/ ? ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
[ClusterLabs] Antw: Re: Q: Recommened directory for RA auxillary files?
>>> Ken Gaillot schrieb am 03.09.2019 um 16:35 in Nachricht <979978d5a488aabd9ed4a941ff4eac60c271c84d.ca...@redhat.com>: > 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. So what concrete path are you suggesting? /usr/lib//? > > If you want to follow the FHS, you might consider /usr/share if you're > installing via custom packages, /usr/local/share if you're just > installing locally, or /srv in either case. I thought about it, comiong to the conclusion that sharing RA agents and parts of it may not make much sense for HA trying to have independent nodes. > ‑‑ > Ken Gaillot > > ___ > 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/
