[OCF] ocf-shellfuncs standardization - Comments? Objections?

[Alan Robertson]

Ragnar Kjørstad wrote:
> On Sun, Jul 03, 2005 at 04:32:36PM -0600, Alan Robertson wrote:
>>>http://refspecs.freestandards.org/LSB_2.1.0/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
>>>
>>>log_success_msg, log_failure_msg and log_warning_msg.
>>OK.
>>
>>Those don't serve the same purpose as we're trying to do.
>>
>>These are only for the final "I'm done and everything is success or 
>>failure or warning" - and they only go to the pre-boot console (in 
>>practice).
> 
> I can't find anything in the documentation that indicates that they are
> only for the final message. 
> 
>>We need things which also allow informative messages, debug messages, 
>>and which don't (in practice) print funny reverse video thing, and which 
>>don't go to the pre-boot console.
> 
> The LSB only defines what the functions are, not what they should do.
> 
> If a script is executed as a regular init script, the scripts should
> probably forward the data to the screen, as they do with Red Hat and
> SUSE initscripts.
> 
> If the script is executed in the OCF environment the same functions
> should (IMHO) be defined to send the messages to the Resource Manager,
> and then it would be up to the RM to decide what to do with them.
> 
> I agree though, that the 3 functions should be complemented by
> log_info_msg and log_debug_msg (and possible others), which could be
> NOOPs in regular initscripts but still do something in the OCF
> environment. (Actually, it would be very useful if one could enable
> debugging for regular initscripts as well, e.g. by setting an
> environmentvariable LSB_DEBUG)

You can't find my descriptions in the LSB - because the aren't so well 
defined as that.

But, in practice that's what they do, and that's what they're *expected* 
to do.

One of the nice things about the ocf_log functions as we have 
implemented them is that they work a lot more like syslog - they 
automatically include date/time/scriptname in the output.

Do you know of a good way to implement what you've suggested?  That is, 
to have them do whatever the local LSB implementation does when not 
invoked with OCF vars not set, and to have them do what the local OCF 
implementation wants, when they're invoked in the OCF environment.  I 
guess I know of one way.  Maybe you can suggest a better one?

The way I know of is to have a dot-included file that redefines what 
those functions do, and then "dot-include" that file when in the OCF 
environment.  That'd work.  Not too elegant, but should be effective.

And, adding an LSB_DEBUG and/or OCF_DEBUG flags.  That sounds like a 
good idea.

LMB:  What do you think about this?

-- 
     Alan Robertson <alanr at unix.sh>

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