Date: Tue, 16 May 2006 13:35:51 -0400 (EDT) From: "Brian A. Seklecki" <lavalamp@spiritual-machines.org> To: ocf@lists.community.tummy.com, freebsd-rc@freebsd.org, tech-userlevel@netbsd.org Cc: General Linux-HA mailing list <linux-ha@lists.linux-ha.org> Subject: Integrating OCF framework w/ (Net|Free)BSD rc.d Message-ID: <20060513015129.C95601@arbitor.digitalfreaks.org>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?20060513015129.C95601>