What is OCF? The extensions required to make any RC script register a 
system service as a Cluster Resource in the Linux-HA infrastructure.

For those of you unfamiliar with OCF, please refer to the draft standard 
at: 
http://www.opencf.org/cgi-bin/viewcvs.cgi/specs/ra/resource-agent-api.txt?rev=HEAD
http://linux-ha.org/HeartbeatResourceAgent
http://linux-ha.org/LSBResourceAgent
http://linux-ha.org/OCFResourceAgent
http://linux-ha.org/ResourceAgentSpecs

Fortunately, our rc.d system infrastructure is sufficiently extensible in 
nature to easily mitigate the need for duplicate OCF script coding efforts 
by Port maintainers.  Existing in-tree and Ports-provided rc.d/ compliant 
scripts can be extended with very little effort.

However some discussion would be prudent as to how to best accomplish the 
task most conducive

==

*) Exit codes

We deviate slightly from LSB, as so does LSB from OCF.

Example: When we execute a "stop" command to run_rc_command() on an 
already stopped service, we return code "1", while OCF/LSB calls for code 
3.  We could put a conditional check around the return/exit statement, 
however OCF "compatibility mode" would need to be a variable we source in 
from the service's RC script.  like 'checkyesno $ofc_compat' at line 691 
in rc.subr

There are other adjustments to exit codes that would so need to be made 
(see the standards doc)

*) Environmental variables for per-instance services

Currently we don't have a uniform method for dealing with multiple 
instances of services.  The Apache2 method is nice ("Profiles"); -- 
"apache2.sh [instance] [argument]" syntax.  OCF scripts expect to be 
differentiate using exported environmental variables from the calling 
application: OCF_RESKEY_*, which is not an issue.

*) Additional arguments

The spec calls for additional arguments "monitor" (to augment the existing 
"status") as well as "metadata" (to describe the service using an XML DTD) 
and an optional "validate-all".

These can be very easily implemented using a $extra_commands="".

   extra_commands="monitor metadata"

   monitor_cmd="slapd_monitor"
   metadata_cmd="slapd_metadata"

Note: commands with hyphens (or function names) in them do not seem to be 
honored.  'monitor' should hypothetically be an intelligent service check, 
more than just checking if a TCP socket is open but also if the service is 
healthy -- which implies calling/exec'ing an outside program, like a 
Nagios health check.  Something that generates dynamic input and checks it 
against generated output.

Note: None of the included OCF examples do truely objective testing yet! 
(Sorry guys, systems that don't permitted fragmented packets to the 
network broadcast address aren't going to run Apache's mod_status by 
default }:> ).  We can leave the $servicename_monitor() symantics up to 
the port maintainer, plus the end user can always do more aggressive 
checking.

However, our current "status" routine checks for the existence of a PID 
file and cross-references it against the process list (which is a more 
extensive than most other RC systems).  Given that, as a temporary fix, 
"monitor" can be easily mapped to "status" using a small code snippit:

   slapd_monitor ()
   {
    run_rc_command status

    case $? in
           1)
                   exit 7
                   ;;
           *)
                   exit 0
                   ;;
           esac
   }

--

As for the "metadata" and "validate-all" routines, the XML DTD simply 
helps describe the command line and environmental variable arguments valid 
for the OCF service script, so we might be able to develop a reusable set 
of routines for generating the output without any crazy dependencies on 
libXML.

The trickier question arises when we want to start making in-tree rc.d/ 
scripts OFC compliant/compatible (nfsd, named, inetd, sendmail, ntpd, 
etc. come to mind)

I'm interested in any discussion / thoughts on a strategy or apporach for 
coding OCF compatibility / integration into our rc.d/ system

Thanks,

~BAS