Re: [ClusterLabs] Antw: Re: Q: The effect of using "default" attribute in RA metadata
On Thu, 2019-09-05 at 09:31 +0200, Ulrich Windl wrote: > > > > Tomas Jelinek schrieb am 05.09.2019 um > > > > 09:22 in > > Nachricht > <651630f8-b871-e4c1-68d8-e6a42dd29...@redhat.com>: > > Dne 03. 09. 19 v 11:27 Ulrich Windl napsal(a): > > > Hi! > > > > > > Reading the RA API metadata specification, there is a "default" > > > attribute > > > > for "parameter". > > > I wonder what the effect of specifying a default is: Is it > > > purely > > > > documentation (and the RA has to take care it uses the same default > > value as > > in the metadata), or will the configuration tools actually use that > > value if > > the user did not specify a parameter value? > > > > Pcs doesn't use the default values. If you don't specify a value > > for an > > option, pcs simply doesn't put that option into the CIB leaving it > > to > > the RA to figure out a default value. This has a benefit of always > > following the default even if it changes. There is no plan to > > change the > > behavior. > > I see. However changing a default value (that way) can cause > unexpected > surprises at the user's end. > When copying the default to the actual resource configuration at the > time when > it was configured could prevent unexpected surprises (and the values > being used > are somewhat "documented") in the configuration. > I agree that it's no longer obvious then whether those default values > were set > explicitly or implicitly, > > > > > Copying default values to the CIB has at least two disadvantages: > > 1) If the default in a RA ever changes, the change would have no > > effect > > ‑ a value in the CIB would still be set to the previous default. > > To > > configure it to follow the defaults, one would have to remove the > > option > > value afterwards or a new option to pcs commands to control the > > behavior > > would have to be added. > > Agreed. > > > 2) When a value is the same as its default it would be unclear if > > the > > intention is to follow the default or the user set a value which is > > the > > same as the default by coincidence. > > Agreed. > > Are there any plans to decorate the DTD or RNG with comments some > day? I think > that would be the perfect place to describe the meanings. The standard has its own repo: https://github.com/ClusterLabs/OCF-spec The ra/next directory is where we're putting proposed changes (ra- api.rng is the RNG). Once accepted for the upcoming 1.1 standard, the changes are copied to the ra/1.1 directory, and at some point, 1.1 will be officially adopted as the current standard. So, pull requests are welcome :) I have an outstanding PR that unfortunately I had to put on the back burner but should be the last big set of changes for 1.1: https://github.com/ClusterLabs/OCF-spec/pull/21/files > > Regards, > Ulrich -- Ken Gaillot ___ 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 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: Q: RA metadata description
Hi again, while writing a longer I could imagine this minimal markup (like in stackexchange): * Lines are filled and wrapped normally * Lines ending with two spaces cause a line break A sequence of empty lines (including one that consists of white space only) starts _one_ new paragraph. I think this minimal markup would be extremely helpful to format the output. Something like nroff's .TP (tagged paragraph) for itemized or numbered lists look like a good idea also, but that harder to implement than the suggestions above. Regards, Ulrich >>> "Ulrich Windl" schrieb am 05.09.2019 um 08:37 in Nachricht <5d70ad3802a100033...@gwsmtp.uni-regensburg.de>: > Hi! > > The desription of RA metadata is poor for years (e.g. the DTD has almost no > comments) (I still prefer the DTD for readability over the RNG), and working > on an RA I have a question: > > How is the to be formatted? A "crm ra info " des not seem to wrap > long lines at terminal width. So are the long lines in expected to > be wrapped in XML? Even if not, for practical reasons of readability the > lines may be wrapped manually in XML. > So are there any formatting rules, or maybe even some markup? > > BTW: Is there a reason why the DTD is named "ra‑api‑1.dtd", while the RNG is > named "metadata.rng"? > > Regards, > Ulrich > > P.S. Here's the "well‑documented" DTD: > > > > nameCDATA #REQUIRED > version CDATA #IMPLIED> > > > > > > > > > nameCDATA #REQUIRED > required (1|0) "0" > unique (1|0) "0"> > > > langNMTOKEN #IMPLIED> > > > langNMTOKEN #IMPLIED> > > > type(string|integer|boolean|time)#REQUIRED > default CDATA #IMPLIED> > > > name > (start|stop|recover|monitor|restart|migrate_to|migrate_from|promote|demote|no > tify|status|reload|meta‑data|usage|methods|validate‑all) #REQUIRED > timeout CDATA #REQUIRED > intervalCDATA #IMPLIED > start‑delay CDATA #IMPLIED > roleCDATA #IMPLIED > depth CDATA #IMPLIED> > > > > ___ > 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/
[ClusterLabs] Antw: Re: Q: The effect of using "default" attribute in RA metadata
>>> Tomas Jelinek schrieb am 05.09.2019 um 09:22 in Nachricht <651630f8-b871-e4c1-68d8-e6a42dd29...@redhat.com>: > Dne 03. 09. 19 v 11:27 Ulrich Windl napsal(a): >> Hi! >> >> Reading the RA API metadata specification, there is a "default" attribute > for "parameter". >> I wonder what the effect of specifying a default is: Is it purely > documentation (and the RA has to take care it uses the same default value as > in the metadata), or will the configuration tools actually use that value if > the user did not specify a parameter value? > > Pcs doesn't use the default values. If you don't specify a value for an > option, pcs simply doesn't put that option into the CIB leaving it to > the RA to figure out a default value. This has a benefit of always > following the default even if it changes. There is no plan to change the > behavior. I see. However changing a default value (that way) can cause unexpected surprises at the user's end. When copying the default to the actual resource configuration at the time when it was configured could prevent unexpected surprises (and the values being used are somewhat "documented") in the configuration. I agree that it's no longer obvious then whether those default values were set explicitly or implicitly, > > Copying default values to the CIB has at least two disadvantages: > 1) If the default in a RA ever changes, the change would have no effect > ‑ a value in the CIB would still be set to the previous default. To > configure it to follow the defaults, one would have to remove the option > value afterwards or a new option to pcs commands to control the behavior > would have to be added. Agreed. > 2) When a value is the same as its default it would be unclear if the > intention is to follow the default or the user set a value which is the > same as the default by coincidence. Agreed. Are there any plans to decorate the DTD or RNG with comments some day? I think that would be the perfect place to describe the meanings. Regards, Ulrich ___ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/
Re: [ClusterLabs] Q: The effect of using "default" attribute in RA metadata
Dne 03. 09. 19 v 11:27 Ulrich Windl napsal(a): Hi! Reading the RA API metadata specification, there is a "default" attribute for "parameter". I wonder what the effect of specifying a default is: Is it purely documentation (and the RA has to take care it uses the same default value as in the metadata), or will the configuration tools actually use that value if the user did not specify a parameter value? Pcs doesn't use the default values. If you don't specify a value for an option, pcs simply doesn't put that option into the CIB leaving it to the RA to figure out a default value. This has a benefit of always following the default even if it changes. There is no plan to change the behavior. Copying default values to the CIB has at least two disadvantages: 1) If the default in a RA ever changes, the change would have no effect - a value in the CIB would still be set to the previous default. To configure it to follow the defaults, one would have to remove the option value afterwards or a new option to pcs commands to control the behavior would have to be added. 2) When a value is the same as its default it would be unclear if the intention is to follow the default or the user set a value which is the same as the default by coincidence. Regards, Tomas I would favor the second, of course ;-) 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/
