[Pacemaker] Newcomer's question - API?

[Andrew Beekhof]

On Wed, Nov 2, 2011 at 8:22 PM, Tim Ward <Tim.Ward at ipaccess.com> wrote:
> Thanks all for the help so far.
>
>> One wonders why you want to write something from scratch in Java,
> though.
>
> Well, we don't, of course. The ideal would be to use an existing,
> documented, non-GPL, interface library.

LGPL?  What license would your code be under?

> As we have not yet identified
> any such thing we have been considering other options, one of which is
> to reverse engineer the protocol and write something from scratch - this

It is not my intention that people would be forced to do this in order
to develop against Pacemaker.

> is obviously possible, but also obviously tedious, and is thus a
> back-stop fallback option, albeit not an attractive one, if we can't
> find a better approach.
>
>> 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]).
>
> I appreciate that an option is to call the command line interface from
> Java, but that gives the problem of parsing the textual output or
> otherwise determining whether the command worked, and if not why not, so
> as to be able to code useful error handling.

For a Java based GUI, you could poke around at
http://hg.clusterlabs.org/pacemaker/gui which I apparently forgot to
add a license to :-)
Its not been updated for many moons and so may or may not work
anymore, but it did at one point and should be enough to get you
started.

> I have not yet found documentation of the output format or return codes
> of these commands. So the worry is that if we write a parser to
> interpret the output as observed by experiment (a) we'll miss some error
> cases that we didn't manage to provoke during our experiments and (b)
> the text output format from the commands might change in a new version.

Generally, since they all end up sending XML to the CIB, they return
CIB error codes which are documented in the header file.

> Of course if a Java parser for the output already exists somewhere
> (non-GPL) that could be extremely helpful.
>
> -----
>
> So it looks like we currently have a choice of reverse engineering an
> undocumented protocol

There isn't really a protocol as such.  Its just XML messages being
passed back and forth.
The contents of these updates and query results is (mostly[1])
documented in our schemas.
You'll also want to take note of the validate-with field at the top
level which tells you (and Pacemaker) which version of the schema is
being used.

The following URL has some information on how it is used by the project:
   http://theclusterguy.clusterlabs.org/post/441442543/new-pacemaker-release-series


Hope that helps

[1] Except for some scaffolding, which hasn't changed in forever :-)

> and hoping it remains stable (or even in
> existence!) over new versions, or reverse engineering some
> human-readable text output from a human-targeted CLI and hoping that
> remains stable over new versions, which is clearly not an ideal position
> to be in.
>
> We must have missed something ... ... ... ???
>
> Tim Ward
> Brett Ward Limited - www.brettward.co.uk
>
>
>
>
>
> This message contains confidential information and may be privileged. If you are not the intended recipient, please notify the sender and delete the message immediately.
>
> ip.access Ltd, registration number 3400157, Building 2020,
> Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
>
> _______________________________________________
> Pacemaker mailing list: Pacemaker at 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
>