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
tser...@suse.com
_______________________________________________
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
