[Pacemaker] Language bindings, again (was Re: Newcomer's question - API?)

[Florian Haas]

On 2011-11-02 04:33, Tim Serong wrote:
> <ianal>I vaguely recall reading the FSF considered headers generally
> exempt from GPL provisions, provided they're "boring", i.e. just
> structs, function definitions etc.  If they're a whole lotta inline
> code, things are a bit different</ianal>.

Really?

> Anyway.  Roughly speaking, if we *did* have other language bindings for
> libcib/libpengine, the story would be something like this (Andrew can
> correct me if I'm wrong):
> 
> libcib would let you manipulate the CIB programatically, with much the
> same ability you have when running cibadmin, i.e. you're just
> manipulating chunks of XML.  Unless I'm not paying attention, there's no
> e.g. "create resource" API; your program would have to construct the
> correct XML resource definition then give it to libcib to inject into
> the cluster configuration. Likewise, to stop and start a resource,
> you'll be writing code to set the target-role meta attribute of that
> resource.

I hate to handwave, as due to my practically non-existent C and C++-fu
this is something I can't tackle myself. But let me float this idea here
again.

Coming from Python, what's usually available there is a thin, low-level
wrapper around the C API, plus a high-level object-oriented API that is
the only thing callers ever actually use.

To make this portable to multiple languages, one possible option that's
been suggested to me before is to create an OO C++ wrapper around the
libcib/libpengine C APIs, and then SWIGify that (I do understand Andrew
cringes at that, which I'll just accept for a moment). Such that,
eventually, you might end up with something like

cib = cib.connect()
r = cib.resources.add("p_mysql","ocf:heartbeat:mysql",
binary="/usr/bin/mysqld")
cib.commit()
r.start()

Extrapolate for Perl, Java, PHP, Ruby, or anything else that SWIG supports.

> So you may as well just invoke cibadmin, crm_resource,
> crm_attribute directly.  I think it's safe to assume those interfaces
> are stable.  At a higher level, "crm configure ..." should also be
> considered pretty stable; we know people use it in scripts so we try not
> to break it (and BTW, I use all this stuff in Hawk[1]).

Where I do seem to recall you conceded at one point that firing off a
binary every time you need to get a resource status doesn't exactly
scale to scores of resources in, say, a 16-node cluster, and a Ruby
library interface would be much more useful. Or am I mis-remembering?

Cheers,
Florian

-- 
Need help with High Availability?
http://www.hastexo.com/now