[Pacemaker] how to determin crm version / features from within a RA

[Lars Ellenberg]

On Wed, Jun 10, 2009 at 04:42:32PM +0200, Dejan Muhamedagic wrote:
> On Wed, Jun 10, 2009 at 04:26:31PM +0200, Andrew Beekhof wrote:
> > On Wed, Jun 10, 2009 at 3:53 PM, Lars
> > Ellenberg<lars.ellenberg at linbit.com> wrote:
> > > taking this to the pacemaker list...
> > >
> > > On Wed, Jun 10, 2009 at 02:53:24PM +0200, Andrew Beekhof wrote:
> > >> since 1.0.4, giving --version to almost any of the crm tools will give
> > >> you the current version number.
> > >> it also includes the supported stacks and (if built correctly) the Hg
> > >> changeset used.
> > >
> > > unfortunately all of them also print the full help text to stdout
> > 
> > They dont here...
> > Were the packages built with getopt-long?
> > 
> > > _and_ exit 0 for unrecognized options.
> > 
> > Ok, thats bad.  I'll get that fixed.  (I can see this part locally too)
> > 
> > > so I need to parse the output to see if I actually got the version,
> > > and which one.
> > >
> > > maybe I can go for the dc-version?
> > >
> > > but wait:
> > > cibadmin -Ql -o crm_config | grep cib-bootstrap-options-dc-version
> > >
> > > pacemaker:
> > > <nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="1.0.4-3917b11b3a14+ stable-1.0 tip"/>
> > > heartbeat 2.1.4:
> > > <nvpair id="cib-bootstrap-options-dc-version" name="dc-version" value="2.1.4-node: --node-hash--"/>
> > >
> > > darn.
> > > special case version compare:
> > > ?1 > 2 for extremly legacy values of 2.
> > 
> > I think its going to be many years before we see a pacemaker version
> > starting with 2.
> > So thats a valid pacemaker/legacy check.
> > 
> > > so...
> > > what is the most easy way to reliably distinguish
> > > legacy heartbeat crm 2.0.7, 2.0.8, 2.1.3, 2.1.4
> > > pacemaker crm 0.6, 1.0, 1.x, 2.y (once it is there)
> > > regardless of cluster stack?
> > >
> > > or more specifically, I'd like to be able to see am I running on legacy
> > > heartbeat crm, or pacemaker crm, and then "require" a version. ?I don't
> > > really care for what comm layer is in use.
> > 
> > crmadmin has always supported the --version option, so i think parsing
> > that is one option.
> > and if its not working correctly now, then I'll get it fixed for the
> > next version.
> > 
> > the other alternative is to set what value CRM_FEATURE_SET had at the
> > time of the various releases and look for the reskey meta feature set
> > thingy in the RA.
> > it changed reasonably often in the early days and was definitely bumped for 1.0
> 
> IIRC, you also mentioned that the validate-with attribute is only
> available as of pacemaker 1.x. That's what I used in the crm
> shell.

great.
so, to summarize, I hacked up a compare_version.
and I think I even avoided bashisms! that is once in a life time :)

comments?
overkill?
useful?

Thanks,
	Lars


-- 
: Lars Ellenberg
: LINBIT | Your Way to High Availability
: DRBD/HA support and consulting http://www.linbit.com

DRBD® and LINBIT® are registered trademarks of LINBIT, Austria.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: version_compare.sh
Type: application/x-sh
Size: 2748 bytes
Desc: not available
URL: <https://lists.clusterlabs.org/pipermail/pacemaker/attachments/20090610/6999c781/attachment-0001.sh>