On 2008-08-20T14:17:17, Wolfram Schlich <[EMAIL PROTECTED]> wrote:
> > How the service provider arranges their packaging and upgrade strategy
> > is their concern, not ours ;-) How often do you upgrade init scripts
> > without the service?
> An OCF RA is not just an init script -- please do not forget the
> monitor functionality!
I _wrote_ the OCF spec, or at least served as the editor. I'm quite
aware of that ;-)
> Also, a regular init script could differ
> quite a lot from the init script functions (start, stop) of an
> OCF RA (check logic, error handling etc.).
The OCF RA specification is merely an extension of the LSB init scripts;
it's downwards compatible in every way.
It just augments the LSB init script interface with additional
environment variables - such as allowing to specify a particular
instance -, but those could default to the global or all instances.
And yes, it introduces an additional "monitor" call, but that does not
clash with LSB in any way either - it's a "sane" extension to status,
and in fact, you'll find that many "monitor" ops are actually making use
of the status functionality internally.
So there's no point why the LSB script and the OCF RA could not be one
and the same script, sharing much of the logic.
> Also, when I'd find a bug in my RA, I would not want to wait
> for an update of the service package (which would also be quite
> useless for anybody not using the contained OCF RA and thus maybe
> cause unnecessary updates).
Again, that's totally a different question. The service package provider
could very well release just sub-package updates too.
Besides, see above, if the code would be shared more, more people would
benefit from improved LSB scripts too ;-)
> I did not mean that *you* (the developers of the Heartbeat "core")
> should be writing the RAs :)
> But I doubt the regular package maintainers are interested
> in maintaining a Heartbeat OCF RA they might not even be
> using themselves...
The OCF RA is _not_ heartbeat specific.
The OCF interface is also used by RHT's Cluster Suite for example, and
other cluster vendors could adopt it just as well; in fact, quite a few
of them were present when the spec was defined - possibly many others
actually use it as well, but I don't keep track of proprietary/legacy
solutions much ;-)
Regards,
Lars
--
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________________
Linux-HA-Dev: [email protected]
http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev
Home Page: http://linux-ha.org/
