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.ellenb...@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.
version_compare.sh
Description: Bourne shell script
_______________________________________________ Pacemaker mailing list Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker