Date: Thu, 18 May 2006 22:39:47 -0600 From: Alan Robertson <alanr@unix.sh> To: General Linux-HA mailing list <linux-ha@lists.linux-ha.org> Cc: freebsd-rc@freebsd.org Subject: Re: [Linux-HA] Re: Integrating OCF framework w/ (Net|Free)BSD rc.d Message-ID: <446D4C13.6010706@unix.sh> In-Reply-To: <20060518113707.C82296@arbitor.digitalfreaks.org> References: <20060518113707.C82296@arbitor.digitalfreaks.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Brian A. Seklecki wrote:
>
> On Tue, 16 May 2006, joerg@britannica.bec.de wrote:
>
>> On Tue, May 16, 2006 at 01:35:51PM -0400, Brian A. Seklecki wrote:
>> [SNIP]
>>>
>>> I'm interested in any discussion / thoughts on a strategy or apporach
>>> for
>>> coding OCF compatibility / integration into our rc.d/ system
>>
>> Oh my god, another over-complicated Linux "standard" which uses the
>
> A lot of this goes without saying. However, Linux-HA is the only
> available, portable Failover Management Software (FMS) available for
> POSIX compliant systems. It's under active development and the 2.x
> branch has some game.
>
> I'm not talking about changing any default behavior, I'm asking what the
> best strategy would be to put hooks in place to easily enable
> "compatibility" mode.
>
> Adding new commands is easy with $extra_commands, but changing return
> codes requires some if[]'s in-tree. An extra couple of cycles blown
> isn't that bad of a tradeoff to bring high availability (HA) / failover
> features to *BSD.
>
> ~BAS
>
>> kitchen sink approach for system management. I'm strongly opposing
>> changing the current system to comply with this.
I can certainly understand this, but it's actually VERY similar to
existing Linux init scripts. I understand that's not very interesting
to you guys, but part of the design goal was to be able to write an
/etc/init.d script which could ALSO be an OCF script.
I understand about the exit code issues (believe me I do).
But, you gotta start somewhere.
We were not specifically designing OCF to replace init scripts, but to
fill a very specific and necessary role in HA systems based on a good
bit of experience, and input from multiple clueful people. It was based
on some success we'd had in R1, and experience-based realizations of how
to do things better. We could have made it completely different from
init scripts, but we saw advantage to having it be straightforward to
change an init script to be an OCF script. [LOTS of people know about
init scripts - they've been around since shortly after the Beginning Of
Time ;-)].
Here are the differences we HAD to provide over normal init scripts:
1) Support for multiple instances
2) Uniformity of everything (no special cases for
filesystems and IP addresses)
(this requires item (1) above)
3) Need to do monitoring - explicitly more powerful than
"status"
And, we wanted it to be completely upwards compatible from existing init
scripts. We didn't want it to require that they be written in the shell
(although that's likely most peoples' choice in practice).
So, that meant no command line parameters. So, everything interesting
gets passed in the environment.
Now, once you have different instances and configuration parameters, you
get into the need to configure it with some kind of configuration tool
as a possibility. And, we needed to know things like timeout values,
parameter descriptions in multiple languages and so on. The observant
will notice that it's very very clumsy to put this into a flat
namespace, but very natural (and extensible) to express in a hierarchy.
To allow multiple languages, and support more metadata, we went from the
"parse the comments in the shell script and get out a few name/value
pairs" technique used by the LSB to something which could provide us a
LOT more information - and in multiple languages, and could continue to
grow without kludges. So, we went with XML. This isn't a wonderful
choice, but there are no good choices for this, so it was by far the
lesser of many evils. HOWEVER, no one needs an XML library in your init
scripts. The strings in the metadata are constants.
And, the nice thing is now anyone who writes an OCF resource agent
automatically gets discovered by us and our GUI can prompt them for how
to configure the instance. This is REALLY COOL (IMHO). PS: if you
check the current CVS, our GUI is significantly improved over the 2.0-5
GUI. You just can't stop that Huang Zhen!
Of course, you don't _have_ to use a GUI, but if you _want_ to, then
having this support for it is essential. Since we were designing for HA
systems and most of them have GUIs, it's not optional for the purpose of
the standard. Of course, the metadata is also useful for a curses tool,
or even a configuration validator.
We have also extended the OCF spec ourselves in R2 for more powerful
capabilities, and that was really easy and natural given how it was all
put together. Some of those extensions will definitely get rolled back
into the spec.
Since it's a standard, we wanted to have various people provide scripts
and NEVER have them overwritten by the next generation of system
scripts, or have other name clashes between different vendors. So, we
added in the "provider" level in the directory hierarchy. This was
simple to do, and really goes a long way to making this long-standing
and annoying problem go completely away. [The only piece missing would
be an IANA type provider registration process - which is only necessary
if we are an incredibly wild success ;-)].
To my knowledge, the only thing(s) we could have eliminated from what we
did was:
- not support multiple levels of monitoring
- POSSIBLY eliminate the provider level in the directory hierarchy.
The multiple levels of monitoring was a natural and simple thing for us
to do on top of what else we were already doing. The provider idea was
just trying to provide a simple solution to a long-standing problem.
All things considered, I'm pretty pleased with how it came out.
--
Alan Robertson <alanr@unix.sh>
"Openness is the foundation and preservative of friendship... Let me
claim from you at all times your undisguised opinions." - William
Wilberforce
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?446D4C13.6010706>