[OCF]Resource Agent Environment variables

[Lars Marowsky-Bree]

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

On 2003-07-19T14:51:14,
   Alan Robertson <alanr@unix.sh> said:

> The mental error is this:  If the scripts have badly named variables in=
=20
> them, then they have a problem.

Yes, that's true. That's why I said that the naming of sysconfig is
slightly outside our scope.

> The possible limitation in benefits is this:
> If the variables that we use have the same names as the variables that th=
e=20
> scripts get out of their funky "sysconfig" files, then the metadata we've=
=20
> added to the files can help the normal system configuration process just=
=20
> like it helps us.

The point is that instance variables should be different from the names
in the syconfig file (so the script can source both), which is best done
by having a special prefix. I, on purpose, do not want them to overlap.

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.

If we shift the responsibility to chose 'non-clashing' parameter names
to where the user sees it; then the instance variables need to be
prefixed accordingly, and that's not a good idea.

OCF-aware scripts will need some minor changes to support instance
parameters anyway. Doing some minor translations for the instance
parameters to the current set of values - which may be as simple as an
assignment - is the least of the problems and keeps some flexibility.

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

> So, SuSE, Red Hat, etc. would be free to reuse the code=20
> we'll write for handling this, and then integrate it into Yast, etc.
> If we don't keep the variable names the same, then the possibility for th=
is=20
> benefit is lost.

? The generic enhancements can be fed back into the system init scripts
/ metadata, no problem. Even the glue logic for OCF can stay in place.
That's totally unrelated to the naming problem.

What naming the script uses internally isn't our problem. But we should
clear up the namespace and not clutter is further.

> If we recommend that agent authors prefix their variables by something=20
> reasonable, and then we use these same variable names in both cases, then=
 I=20
> believe that we really do get the best of both worlds.

The instance parameter names are user visible.

The instance parameters could be different in naming, content and number
from sysconfig data.

> No stupid variable names, simple script commonality, and the ability
> for others to take best advantage of our work.

The glue logic doesn't at all prevent the common scripts.

The ability for others to take advantage of our work isn't at all
affected.

> Does this make sense?

I'm afraid it doesn't make sense to me.


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

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

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

iD4DBQE/HDjDudf3XQV4S2cRAq+zAJwMSc+yYo2m0Ufi3SpmmC2zXQ1wpACXdbYv
FzZDYDZM0VxSilLDK3tEbQ==
=cmm6
-----END PGP SIGNATURE-----

--vOmOzSkFvhd7u8Ms--