[Linux-ha-dev] 3.0 thoughts

[Wolfram Schlich]

* Lars Marowsky-Bree <lmb at suse.de> [2008-08-20 14:50]:
> On 2008-08-20T14:17:17, Wolfram Schlich <lists at wolfram.schlich.org> 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?
> >
> > 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.

There are systems that are not using LSB init scripts at all but that
are still used together with software using OCF RAs (like Heartbeat,
for example).

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

I doubt anyone would do that for "just" one OCF RA. But anyway.

> Besides, see above, if the code would be shared more, more people would
> benefit from improved LSB scripts too ;-)

See above -- there are systems that do not use LSB init scripts at all.

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

Let me rephrase it: I doubt the regular package maintainers are
interested in maintaining OCF RA specific code they might not even be
using themselvens...

IMHO a service package is just the wrong place for stuff specific to
external software like cluster management (resource agents) or
monitoring (check scripts) software.
The specific/extra knowledge that is needed to correctly deal with
it is more on the side of the external software than on the side of
the service package, IMHO.
That means, it's easier for me as an OCF RA developer to create
an OCF RA from an existing init script than for a service init
script developer to create an OCF RA, because the service init script
developer would have to gather a lot more new knowledge about
the OCF stuff than I would have to gather about the init script...
Just my opinion.
-- 
Regards,
Wolfram Schlich <wschlich at gentoo.org>
Gentoo Linux * http://dev.gentoo.org/~wschlich/