[OCF]Resource Agent Environment variables

[Alan Robertson]

Lars Marowsky-Bree wrote:
> 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 
>>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.

So, don't solve it.  Leave it alone.


>>The possible limitation in benefits is this:
>>If the variables that we use have the same names as the variables that the 
>>scripts get out of their funky "sysconfig" files, then the metadata we've 
>>added to the files can help the normal system configuration process just 
>>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.

So, tell people to make such prefixes. Don't add them automatically.  Should 
it be "home" or "casa"?  If you want to call it home, then give it the name 
home in the native language through the "shortdesc".  If you're planning on 
showing the untranslated name to humans, then you're making a mistake. 
That's why I suggested the short and long descriptions in the first place.

> 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.

It is inappropriate to show end-users these parameter names.  You have a 
shortdesc and the longdesc.  There is no reason to think that any end-user 
human beings (other than debuggers) want to see the parameter names.  They 
aren't in the native langauge, among other things...

> 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.

Complexity is the enemy of reliability.

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

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


>>So, SuSE, Red Hat, etc. would be free to reuse the code 
>>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 this 
>>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.

Sounds like I didn't communicate this so that you got it.  This is the main 
point.  If you didn't get it, then you missed out.  Let me repeat it and see 
if I make it specific for your distro, if I can make it any clearer.

Right now, SuSE has an administrative tool called yast2.  It allows users to 
set parameters for these variables that go with these scripts.  But, it has 
no way to automatically find out the list of parameters, or validate the 
results.  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).

So, any code which can invoke a resource agent and ask it what parameter 
names it supports, and can validate the results can be used for either 
validating cluster parameters, or init script parameters -- if and only if 
the variable names are the same for the script when invoked as a resource 
script and as invoked as an init script.

So, if I write a piece of code which can tell you the set of variable names 
which occur in the resource agent, and can then pop up a screen and display 
the dialog boxes to configure them, and I have a piece of code which I can 
use to configure the cluster.

If the variable names are exactly the same for the usage as a resource 
script and the usage-as-an-init script, then this EXACT same piece of code 
can be used in a tool like yast2.   But, if you make the variables 
different, then you're screwed [in addition to making yourself reviled for 
forcing unnecessary work on people].


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

They are not in the native language. Why would you show a 
semi-english-semi-C-semi-shell-script name to someone who only speaks 
Chinese?  You'll show users the short and long descriptions - because 
they're in the native language.  The variable names are the names for the 
programmers, not the users.  That's why they're not translated into the 
native language.  They're only for communicating to programs.

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

To my knowledge there is no reason to do that. At least, you haven't 
presented one yet.

If the resource script is common, then whatever you want to set from the 
normal admin interface is almost certainly something you'd want to set from 
the cluster interface.  The reverse is almost certainly true too...

If you have a real example of a real script where this is clearly 
undesirable, please let put in in your reply along with an explanation.  I 
looked at a few init scripts, and thought about the resource scripts I've 
written, and I none come to mind either from example or intuition.

>>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.

I said it would work in my previous email.  I also said it makes them more 
complex, ugly, error-prone and kludgy.    Ugly and kludgy because you have 
unnecesssary code which isn't needed except for a defect in the standard. 
More complex because you have to add more code.   Error-prone because you 
can easily add parameters and forget to map across, or map across correctly. 
  If you make them the same you CANNOT screw it up.  It's an unnecessary and 
non-functional potential source of errors.

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

I believe this is false.  See argument in previous email which you didn't 
reply to, and the longer explanation above...



-- 
     Alan Robertson <alanr@unix.sh>

"Openness is the foundation and preservative of friendship...  Let me claim 
from you at all times your undisguised opinions." - William Wilberforce