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

[Alan Robertson]

Lon Hohberger wrote:
>>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:

I think the section of the spec you're referring to is only for the status 
operation.  I believe that we are painfully in compliance with the spec on 
both the status operation, and the non-status operations.

[PS: Lon already knows this, this is mainly for the others on the list, and 
the archives].

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