[OCF]Resource Agent Environment variables

[Alan Robertson]

Lars Marowsky-Bree wrote:
> On 2003-07-18T17:14:10,
>    Alan Robertson <alanr@unix.sh> said:
> 
> 
>>So, one could make this script usable as both a resource agent, and an init 
>>script, one could change that first line so that it looked more like this:
>>	test "X$OCF_RA_VERSION_MAJ" = X && . /etc/syconfig/syslog
> 
> 
> Indeed.
> 
> 
>>And then this script could be called either as an OCF resource script, or 
>>as an init script with very minimal changes.  However, there is one rub, 
>>which I'd like to make go away...
> 
> 
> I sort of agree, but not with the solution ;-)
> 
> 
>>In Section 3.5.1, the spec says:
>>
>>>3.5.1. Syntax for instance parameters
>>>
>>>They are directly converted to environment variables; the name is prefixed
>>>with "OCF_RESKEY_".
>>>
>>>The instance parameter "force" with the value "yes" thus becomes:
>>>	OCF_RESKEY_force=yes
>>>in the environment.
>>>
>>>See section 4. for a more formal explanation of instance parameters
>>
>>This make it incompatible with common usage in current init scripts.  And, 
>>given the advantages that we *almost* have, I'd like to drop the prefix 
>>from environment variables.  This would make it more palatable, I think, 
>>and easier to treat an only-slightly-hacked init script directly as an init 
>>script.  A proposed new Section 3.5.1:
>>
>>-------------------------------------------------------------------------
>>3.5.1. Syntax for instance parameters
>>
>>They are directly converted to environment variables.  There is no prefix 
>>added to the environment variables.
>>
>>The instance parameter "force" with the value "yes" thus becomes:
>>	force=yes
>>in the environment.
> 
> 
> Imagine an instance parameter called "HOME", no_proxy etc. Whoa, clash!
> 
> That the sysconfig files tend to clutter the environment isn't all that
> great and not exactly an example to be followed to the dot ;-) They
> should, I think, indeed use a prefix or at least on parsing should be
> prefixed with SYSCONFIG_${FILENAME}_...., because it's a royal pain in
> the butt (in theory) to load two sysconfig files with overlapping
> variable names, but that's an LSB discussion and doesn't belong here.
> 
> Also there may be differences between the exact interpretation of
> instance variables vs global ones. At least there may be more of them
> for an instance, global ones may have different defaults, and even
> though you are an instance, you may still want to know the 'global'
> configuration to interact with.
> 
> So we don't want to create an implicit overlap which is hard to break.
> 
> I'd suggest using glue code like
> 
> . /etc/sysconfig/script
> if [ -n "$OCF_RA_MAJOR" ]; then
> 	SCRIPT_FOO="${OCF_RESKEY_force}"
> 	SCRIPT_BAR=$(grep ${OCF_RESKEY_mount} /etc/fstab)
> 	if [ -z "$SOME_VARIABLE_FROM_SYSCONFIG" ]; then
> 		# option not set, need to handle reskey differently
> 		...
> 	fi
> 	...
> fi
> 
> to translate. The surgery required is still pretty minor and allows us
> to preserve the best of both worlds.
> 
> Would that be acceptable?

Clearly it would work.

I think you're making a small mental error here, and as a result, possibly 
limiting the ultimate benefits from our efforts.

The mental error is this:  If the scripts have badly named variables in 
them, then they have a problem.  They had a problem before we got here, and 
they'll have a problem after we go away.  We are not responsible for that 
problem, nor can we fix it.  In Short:  This Is Not Our Problem.

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

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.  No stupid variable 
names, simple script commonality, and the ability for others to take best 
advantage of our work.

Does this make sense?


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