Hi, On Wed, Aug 11, 2010 at 03:59:34PM -0700, David Lang wrote: > 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.
Yes. But crm shell is not a special tool, such as tools for windows registry or aix objdb. The idea of the shell language is to have a 1-1 translation to XML and back. > 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. Why would that be? If you do crm configure edit it will take you straight to the editor and the saved changes are going to be applied to the cluster. There's also (in v1.1) crm configure filter which can be used with say sed. There's also a way to load/save configurations from/to regular files. As for the management, how do you make a node standby now? hb_standby, right? How's that different from "crm node standby"? > >> 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? Yes. I doubt very much that v1 functionality got broken with the split. > >> 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. The heartbeat codebase as well as the libraries (clplumbing), i.e. the parts which are relevant to v1, haven't changed much in the last few years. > >> 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. I'd say that running something one can't understand is at least unmaintainable. > > 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. I hope that the situation got a bit better recently. One still needs quite a bit of time to devote to learn it, but simple clusters should really not be a problem anymore. > 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. Those logs have always been the same. > 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. And, for the time being, they should work. Don't know what will the future bring, didn't notice much interest in supporting that. Perhaps somebody from Linbit can comment too. > 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. If there are enough shops interested in running v1, then somebody will probably support it too. Thanks, Dejan > David Lang > _______________________________________________ > Linux-HA mailing list > [email protected] > http://lists.linux-ha.org/mailman/listinfo/linux-ha > See also: http://linux-ha.org/ReportingProblems _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
