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

[Nick Stoughton]

On Mon, 2005-07-04 at 17:49, Alan Robertson wrote:
> 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.
> >>
See also the latest version, 3.0, at
http://www.linuxbase.org/spec/booksets/LSB-Core-generic/LSB-Core-generic/iniscrptfunc.html
> >>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. 
These are functions designed exclusively for use in init scripts. If you
are wanting a more general purpose logging function, LSB 3.0 includes
the POSIX "logger" command, which writes to syslog.

> > 
> >>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.
> > 
Well...that's overstating it more than a bit! The LSB definitely defines
what things should do, and the 3.0 versions of the init script logging
functions state that these functions should print a suitable message
(doesn't say where though!)

> > 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.
> 
As I said, they simply cause the message to be "printed" (and in the
implementations I've checked, they simply use "echo" to do that).

> But, in practice that's what they do, and that's what they're *expected* 
> to do.
> 
Yes ... and if you want more, then use the other interfaces defined in
the spec, such as logger.

> 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.
If what you want is syslog, then use "logger".
> 
> 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?