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

[Tim Serong]

On 11/02/2011 06:35 PM, Florian Haas wrote:
> 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?

Here's a rough citation:

http://linux.slashdot.org/story/11/03/20/1529238/rms-on-header-files-and-derivative-works

(No, I didn't read the source material or any of the comments)

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

No objection to that in principle - the major part of the work there is 
(or should be) the wrapper layer though, not the SWIG bits.

By contrast, SWIGing what we have now would only give the thin, 
low-level wrapper you referred to above.  Any anyone using that thin 
wrapper would probably need to go read crm_resource.c or crm_mon.c to 
figure out how to use it :)

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

No, you're not misremembering, but my previous email maybe could have 
been clearer...  For creating/modifying resources, IMO there's minimal 
overhead in invoking crm, or cibadmin or whatever, because you usually 
only have one-ish invocation(s) per create/edit/delete.

Getting status is the annoying thing.  The only way I know to do it 
comprehensively that doesn't involve multiple invocations of some CLI 
tool is to run "cibadmin -Q", then interpret the status section, which 
is what I do in Hawk.  This means I now have a few hundred lines of 
fairly hairy Ruby code which reimplements a few of Pacemaker's pengine 
status unpack functions.  Which works, BTW.  But it doesn't really help 
anyone else, and TBH SWIG bindings would serve Hawk better here anyway, 
because then status calculation would only happen in one place 
(pengine), which would mean zero possibility of 
drift/misinterpretation/confusion.  Blah.

I do actually want to do the SWIG bindings at some point (it still 
hasn't filtered to the top of my list, and I wouldn't complain if 
someone beat me to it), but I want to make sure that whatever we do 
here, we get it "right", because once it's there, we'll have to support it.

Regards,

Tim
-- 
Tim Serong
Senior Clustering Engineer
SUSE
tserong at suse.com