[OCF]Resource Agent Environment variables

[Lars Marowsky-Bree]

--Bqc0IY4JZZt50bUr
Content-Type: text/plain; charset=iso-8859-1
Content-Disposition: inline
Content-Transfer-Encoding: quoted-printable

On 2003-07-21T15:11:33,
   Alan Robertson <alanr@unix.sh> said:

> >Yes, that's true. That's why I said that the naming of sysconfig is
> >slightly outside our scope.
> So, don't solve it.  Leave it alone.

Right. So I don't want to overlap with that, so I don't have to ;-)

> >The other point is that they should have a special prefix so they cannot
> >easily clash with other environment variables at all. And 'home' is a
> >perfectly well named instance variable for certain scenarios.
>=20
> So, tell people to make such prefixes. Don't add them automatically. =20

This isn't a big difference. Whether I add them automatically or make it
an RFC-style 'SHOULD' will, in reality, not change it much.

> Should it be "home" or "casa"?  If you want to call it home, then give it=
=20
> the name home in the native language through the "shortdesc".  If you're=
=20
> planning on showing the untranslated name to humans, then you're making a=
=20
> mistake. That's why I suggested the short and long descriptions in the=20
> first place.

This is a good point. So showing them to humans probably isn't much of a
concern.

I _do_ still want to keep the instance parameters in a distinct
namespace from regular environment variables, though, and consistently
so. So that all OCF related environment variables can be easily
distinguished.

> >I'm a big fan of clear namespaces. A OCF_ prefix is the most simple way
> >to have that in the environment.
> Complexity is the enemy of reliability.

Exactly. Cluttering up the environment, making it hard to both parse the
global configuration files and the OCF parameters at the same time,
doesn't strike me as less complexity.

> I'm a big fan of clean, reliable code.  Your proposal makes the code more=
=20
> complex, less clean and therefore less reliable.

I fear I disagree quite a bit, my view is exactly the opposite.

> Having two names for exactly the same variables is insanity.   Forcing=20
> people to do that is criminal.  Forcing them to assign VAR=3D$OCF_VAR is =
an=20
> unnecessary source of errors.  My proposal gives you clean namespace and=
=20
> clean code.  Yours gives a clean namespace and ugly, error-prone code.

I believe that instance parameters are quite distinct from the variables
under /etc/sysconfig at least as often as not.

Please check the configuration data which is given under /etc/sysconfig.
A brief inspection shows that very little there identifies an
_instance_, but instead gives a full configuration profile for the
global one.

This is very reasonable, as the /etc/sysconfig files do exactly that:
They configure the global instances. (The network files being an
exception).

But this is very different from what our meta-data is about: We need to
identify a unique instance, not give the full configuration of one. We
may point at the configuration files specific to an instance, which then
could be in sysconfig format, but that's still different.

> Right now, SuSE has an administrative tool called yast2.  It allows users=
=20
> to set parameters for these variables that go with these scripts.=20

Yes.

> But, it has no way to automatically find out the list of parameters,
> or validate the results.

It does, we add metadata to /etc/sysconfig files. This is very limitted
compared to the current RA proposal, but I'm willing to compromise here.
We all know that the metadata description in the RA xml file is only a
discussion starter ;-)

> So, it fundamentally has exactly the same problem we have.  And they
> have exactly the same sets of things they're trying to do it over
> "init scripts".  And, they're even the same variable names (unless you
> screw them up).

No, I disagree. See above. /etc/syconfig contains more or less fine
grained configuration data for the global 'instance', not the data
necessary for the RA to identify which resource instance to act on.

> So, if I write a piece of code which can tell you the set of variable nam=
es=20
> which occur in the resource agent, and can then pop up a screen and displ=
ay=20
> the dialog boxes to configure them, and I have a piece of code which I ca=
n=20
> use to configure the cluster.

True. One could consider using the same metadata format here. Even
though I'm dubious, 'cause it means getting even _more_ people to agree
on the metadata description ;-) The metadata format is probably the most
controversial piece we have in that spec.

But that doesn't change the thing that they are different variables &
meaning.

> >The glue logic doesn't at all prevent the common scripts.
> I said it would work in my previous email.  I also said it makes them
> more complex, ugly, error-prone and kludgy.=20

I disagree.


Sincerely,
    Lars Marowsky-Br=E9e <lmb@suse.de>

--=20
SuSE Labs - Research & Development, SuSE Linux AG
 =20
"If anything can go wrong, it will." "Chance favors the prepared (mind)."
  -- Capt. Edward A. Murphy            -- Louis Pasteur

--Bqc0IY4JZZt50bUr
Content-Type: application/pgp-signature
Content-Disposition: inline

-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.0.7 (GNU/Linux)

iD8DBQE/HUqdudf3XQV4S2cRAhzjAJ91NM9WIezD90kXC25n0gVDqXMPfACeMlrI
WWwcftUWdhG6lTqR8FYoLpQ=
=fNuO
-----END PGP SIGNATURE-----

--Bqc0IY4JZZt50bUr--