On Wed, Nov 2, 2011 at 6:35 PM, Florian Haas <flor...@hastexo.com> 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?
>
>> 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).
SWIG, sure
OO wrapper, sure but possibly not in pacemaker
C++, over my dead body
> 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()
Seems reasonable, but IMHO the OO part goes in the Python wrapper that
uses the SWIG bindings.
Eg.
https://github.com/beekhof/pacemaker/blob/openstack/pengine/pacemaker.py.in
> 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
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
> http://oss.clusterlabs.org/mailman/listinfo/pacemaker
>
> Project Home: http://www.clusterlabs.org
> Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
> Bugs:
> http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
>
_______________________________________________
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf
Bugs: http://developerbugs.linux-foundation.org/enter_bug.cgi?product=Pacemaker
