[OCF] OCF RA API 1.0-draft vs. LSB 1.3/2.0-draft

[Lon Hohberger]

>From LSB 1.3 and the 2.0 draft state the following return codes for init
scripts:

0 program is running or service is OK
1 program is dead and /var/run pid file exists
2 program is dead and /var/lock lock file exists
3 program is not running
4 program or service status is unknown

5-99 reserved for future LSB use
100-149 reserved for distribution use
150-199 reserved for application use
200-254 reserved

References:

http://www.linuxbase.org/spec/refspecs/LSB_1.3.0/gLSB/gLSB/iniscrptact.html
http://www.linuxbase.org/spec/booksets/LSB-Core/LSB-Core/iniscrptact.html
http://www.opencf.org/cgi-bin/viewcvs.cgi/*checkout*/specs/ra/resource-agent-api.txt?rev=HEAD&content-type=text/plain


This means that the current OCF RA API draft, as it exists today, is in
conflict with current and the impending future LSB specification.  I
think we should bring the RA API up to date with the current LSB spec.
This basically requires updating resource agent return values so that
(a) they do not conflict with or utilize existing LSB semantics and (b)
so that our application-specific return codes are in the application-
specific reserved area set aside by the LSB spec.

Here's a recommendation for return code changes which would make the OCF
RA API draft LSB 1.3/2.0-draft compliant:

0 program is running or service is OK
1 program is dead and /var/run pid file exists
2 program is dead and /var/lock lock file exists
3 program is not running
4 program or service status is unknown

151 invalid or excess arguments
152 unimplemented feature
153 user had insufficient privileges
154 program is not installed
155 program not configured


Additionally, it turns out that the "monitor" function may not be
needed.  Using the 'OCF_CHECK_LEVEL' environment variable with 'status'
allows you to do both basic status checks and more advanced status
checks without breaking anything if a specific depth isn't handled (for
instance, in a strictly-LSB script used to do the dirty work for a
'script' RA).

This probably wouldn't specifically break anything in the OCF draft or
its goals; the current OCF draft states:

'It is recommended that if a requested level is not implemented, the RA
should perfom the next lower level supported.'

Thus, depth 0, (the example: check for running process), which is also
typically done with the 'status' operation in many LSB scripts, will get
executed if no deeper, more intensive checks are available - writing a
separate 'monitor' function to do this seems like it's duplicating
functionality.


The updates as recommended above would make OCF Resource Agents only
differ by addition of the "meta-data" and "verify-all" (validate-all?)
operations and by overloading the "status" function.  The natural side
effect is that this would allow even easier porting of existing LSB-
compliant init scripts to the OCF RA model; the only change strictly
necessary to turn an LSB init script in to an OCF RA being addition of a
"meta-data" function.

(Side note: the DTD specifies "verify-all"; the text of the draft
specifies "validate-all"... need to pick one.)

-- Lon