On Tue, 9 Sep 2008, Paul Walsh wrote: > In a previous post I mentioned a wiki page. Those familiar with EMC will > know that they have a "compatibility matrix" which is basically where > they certify that SAN product A will work with O/S B on hardware C etc. > > Unless I've missed something somewhere there isn't a similar > table/matrix for Heartbeat and/or Pacemaker. What I have in mind is > something where newcomers can check to see if their intended combination > of Heartbeat (or openAIS), Pacemaker, compiler (environment), O/S and > architecture (SPARC, x86/64, PPC) has been used before successfully and > any pitfalls to watch out for. > > It's obviously not possible for the core developers to test on every > conceivable combination, which is where users "out there" come in. > Experienced (registered?) users would maybe be able to submit details of > new combinations that have worked for them.
For keeping things on track during development: Something I had a little look at (but then got stuck while the rest of 'real life' beckoned me away) was "buildbot": http://buildbot.net/ This is a framework in which lots of different machines, configs and environments, potentially scattered across the globe, all routinely pull a software project, build it and report back successes, warnings and failures to a central place with a web display of those results. A small screenshot from Buildbot themselves: http://buildbot.net/trac/wiki/ScreenShots A much larger one from the python developers: http://www.python.org/dev/buildbot/stable/ > > > o Installation locations. GNU tends to default to "/usr/local/bin" (and > > equivalent locations). We (rightly) need to install in the native-OS > > locations. (That's the rationale for the coding currently inside > > "ConfigureMe" and some of "configure".) > > > > o Scripts (e.g. RAs) ought to be in commonly available languages, shells, > > etc. Any "#!/bin/xxx" must be accurate. In other words a "#/bin/sh" > > must not contain Bash-isms, but a "#!/bin/bash" may make full use of > > 'bash' features. Libraries of 'sh' functions ought to be available to > > any sh-like variant, and so should be kept Bourne-compliant. > Something that "bit" me on Solaris - the startup script placed in > /etc/init.d wouldn't work, until I changed it to #!/usr/bin/bash Ouch! That must be a new-ish one. Release 2.1.3 was in reasonably good shape (although the nasty cl_reboot() argument count seemed to have crept in undetected close to release). And other things (perhaps your bash bug) might well crept in since then. We're digressing from standards. So attempting to get back on track... if we have coding standards, whilst such problems might still arise, at least we would have an agreed framework to recognise and classify such a bug as a deviation from our standards (a real bug) and the guidance for any of our developers then to pull it back on track. -- : David Lee I.T. Service : : Senior Systems Programmer Computer Centre : : UNIX Team Leader Durham University : : South Road : : http://www.dur.ac.uk/t.d.lee/ Durham DH1 3LE : : Phone: +44 191 334 2752 U.K. : _______________________________________________________ Linux-HA-Dev: [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha-dev Home Page: http://linux-ha.org/
