On 11/14/2012 02:17 PM, Lars Marowsky-Bree wrote: > On 2012-11-14T12:44:53, Digimer <[email protected]> wrote: > >> Not really, to be honest. The way I see it is that Pacemaker is in tech >> preview (on rhel, which is where I live). So almost by definition, >> anything can change at any time. This is what happened here, so I don't >> see a problem. > > That is a pretty limited view. Other distros (including one enterprise > one) have already been shipping Pacemaker for production for years, not > to mention the community at large. Andrew has a few years of experience > with supporting paying customers, even ;-) > >> Of course, other distros are free to standardize on crm, lcmc or >> whatever they want. In those distros, perhaps crm remains and will >> remain the default into the future. > > Ah, yes, the sweet smell of distribution differences. Those so > strengthen the Linux environment. > > LCMC and crmsh/hawk are at least conceptionally very very different; > there's no way LCMC could fit the niche that crmsh or hawk fill. And I'm > not even saying crmsh does everything it should (little software ever > does). > > Perhaps a wrapper around crmsh for doing more than just CIB stuff, or > extending the non-CIB stuff it already does (like history browsing, > cibsecrets, etc), would have been feasible. Perhaps fixing some > design/coding deficiencies or even concerns regarding the > maintainership. If any. > > But from the point of view of wanting to grow a user community for Linux > clustering, the admin frontend matters. A lot; that's how admins manage > the cluster; they probably could care less if we have some divergence on > the backend, as long as they can interact with it in the same way. > That's what they care for. Having several *sucks*. Think > documentation. Third party books. Testing. User experience. > Competition with other HA solutions, which can say "Well, > ServiceGuard/Veritas/LifeKeeper work the same on RHEL, SLES, Solaris". > > This *hurts* our story. One should not do that lightly. > > Yet, suddenly there's a new tool, a completely new admin front-end. For > technical reasons, mind. (Just that the commandline looks reasonably > familiar, but not quite, pure coincidence.) That just never were really > spelt out, and when I asked for them (to see if we could find some > common ground, to avoid splitting the front end), I was told to not > mind, because of course everyone is free to work on whatever they want. > Which is probably why there never was a list of suggestions as to what > crmsh could do better. > > Not correlated at all to the maintainership and personal issues, at all, > of course. Right. Sure. If it walks like a duck, if it quacks like a > duck, let's call it a duck. Sorry. Not amused. > > That's not written with my SUSE hat on, by the way. SLE HA 11 is stuck > on whatever anyway, and that's a different story. But with the "argh > must bang my head against a wall must not scream MUST NOT SCREAM" > community hat. > > I can honestly say I'm very sorry. Even if not for the rant above. > > > Regards, > Lars
I'm mixed on my opinion of the issue you've raised. Yes, choice can lead to confusion and confusion hurts adoption. I am sure that was a *huge* factor in the work that started in 2008 to merge the red hat and linux-ha projects into one common cluster stack. No small undertaking. On the other hand though, the ability to create alternatives, fork existing projects and so on is part of why Linux is, over all, such a step up in quality from other operating systems. People are free, for any reason at all, to try new things. Sometimes it is superior, often it is not. In either case, users are free to go where they feel is best. This is what I meant by "choice" being a blessing and a curse". -- Digimer Papers and Projects: https://alteeve.ca/w/ What if the cure for cancer is trapped in the mind of a person without access to education? _______________________________________________ Linux-HA mailing list [email protected] http://lists.linux-ha.org/mailman/listinfo/linux-ha See also: http://linux-ha.org/ReportingProblems
