On Thu, 12 Aug 2010, Dejan Muhamedagic wrote: > On Wed, Aug 11, 2010 at 02:44:36PM -0700, David Lang wrote: >>> haresources2cib.py is obsolete and probably produces a bad >>> cib.xml. The recommended way is to create a configuration using >>> the crm shell. >> >> Ok, so this means that there is officially no migration path for those of us >> using a V1 sty;e config > > haresources2cib had value once the XML was the only way to > configure CRM. I think that converting haresources by hand > doesn't take much effort anymore. It is also a good way to get > acquainted with pacemaker and the crm shell. That was the reason > haresource2cib was retired.
opeque config files that can only be edited with special tools are the bane of sysadmins who need to manage lots of boxes. I currently manage over a hundred clusters of machines. with v1 style configs this is easy to integrate into the other server management tools, if changes had to be done strictly via the crm shell, this is much more complicated. >> This is really starting to sound like we need to fork heartbeat back to the >> 2.x or thereabouts when it could work for simple things easily. > > I can understand the way you feel. But I don't think that there > is a need to maintain the Heartbeat v1 bits separately. With > Heartbeat 3.x you need to install in addition just the > cluster-glue package (perhaps named differently in various > distributions). what would that do? would it let us use v1 style configs where they are suffient? >> does anyone have a good handle on where we should start and what bugs have >> been >> fixed since then (as opposed to new features added, components split out, >> etc)? > > The mercurial repository is the ultimate source. yes, that is the ultimate source, but it's far more painful to have to start from scratch than if someone who is familar with the codebase can provide a map. >> I've been watching things get more and more complicated over time, and I >> recognise that to solve complex problems you sometimes need that complexity, >> but >> there are a LOT of problems that aren't that complex. Heartbeat has been >> making >> it harder and harder to do simple things, and with the difficulty in figuring >> out what version 3.0.2 is doing that Igor is experiancing, and the inability >> to >> take a simple config and convert it to the new format, it is sounding like it >> may be time to fork. > > I completely agree that increased complexity is a problem and > particularly in HA solutions. And it is possible to create very > complex configurations with Pacemaker, and at the same time make > it hard (or impossible) for humans to understand what does the > cluster do. and sometimes such complexity is needed, but sometimes it's not. > However, if you want to run a configuration comparable to v1, > i.e. a simple active-passive or active-active setup, a Pacemaker > cluster is quite manageable. Right now it has all the tools to > make it much easier to manage than a haresources based cluster. > Once you give it a try, you probably won't look back. the problem is that the learning curve has been made so steep that even people who are familar with clusters (and earlier versions of heartbeat) have problems setting up these simple clusters. the fact that we are on day 2 or 3 of Igor's problem and can't even figure out what's happening because the logs aren't showing anything is a very bad sign. I really don't want to have heartbeat fork, but as the project has grown new features and then split off the resource management stuff, the difficulty in getting the simple things working has been growing. most of us who didn't need that complexity just ignored it as long as the haresources configs continued to work. at this point it seems like either the haresources configs need to be un-depriciated and supported, or something else. but the current situation is getting unreasonable. David Lang _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
