On Fri, Nov 16, 2012 at 6:42 AM, Lars Marowsky-Bree <[email protected]> wrote: > On 2012-11-15T09:20:44, Andrew Beekhof <[email protected]> wrote: > >> > LCMC and crmsh/hawk are at least conceptionally very very different; >> Conceptually LCMC and hawk are both web based GUIs, its the >> implementation that makes them so different. > > Not quite. LCMC is pretty heavily different from a deployment > perspective - ssh from where the GUI runs into the server, at the time > we looked. (I admit I'm not upto speed if that is still required.) And > yes, technically Java is a web technology. But. ;-) > > hawk is a server-side running web interface on top of crm shell. > >> pcs is a (remote) shell and a GUI, that sounds pretty different to crmsh to >> me. > > Yes, the remote capability of pcs is different. Though crmsh has some > ability in that regard too. And probably will have to grow them.
And a REST interface and a GUI that talks to it as well? The design Chris has come up with is very nice and you'd have to squint really really hard to make crmsh fit. I could also turn that around and say that pcs is really just ccs growing pacemaker support. With enough work, anything can grow anything. But that doesn't imply its a good idea. > >> But really, does everything in life have to be a "there can be only >> one!" battle? Highlander wasn't a documentary. > > No, of course not. Choice isn't bad. But neither is choice inherently > and always good. > > Especially from the point of view of administrators, particularly the > consistent management story of a cluster stack is tantamount. In my not > humble at all opinion, this is an area where evolutionary improvements > are much better received than radical changes. > > I realize that crmsh doesn't do everything; like all software, it has > bugs, design deficiencies, features that are missing. Yet, > administrators quite like it. So it must have gotten some things > right. > > Before starting with a completely new tool at the most important part of > the stack (the interface to our users), I'd liked to have seen a > discussion if crmsh can't fill the gaps you identified, if we can't grow > the management story consistently. > > And yes, a possible result could have been "No, we cannot, crmsh cannot > grow to accommodate them." And perhaps we'd have had a meta-tool, a > side-by-side tool, which takes care of the bits that crmsh can't. Or > whatever. But there might have been the chance that we could have > avoided this. > > This discussion never happened. (At least not in public, nor with the > maintainers involved.) To be blunt, because it is no more your business than the creation of LCMC or Hawk was mine. As a company, SUSE decided pygui wasn't going to get them to where they wanted to go, went back to the drawing board and decided to create Hawk and chose technologies that complimented SUSE's in-house management framework. I and the community were informed after the decisions was made, there was no request for permission. Nor would that be expected. The only surprise is when some management/marketing type person doesn't try to keep stuff like this a secret so the finished product can be unveiled as a competitive advantage. I understand you think its a really bad idea and that you would have liked the opportunity to talk Chris out of it before it was "too late". But I seriously doubt it would have changed anything. No-one here is thinking "man, we screwed up but its too late to pull out now". You've not managed to convince me and I've also got a fair bit to loose wouldn't you say? > And, strangely, pcs appeared at just about the > time where Dejan decided that crmsh might be better off as its own > project. Who is going to believe the "this had technical reasons" > spiel? Honestly. We have known each other for how long? You want me to > believe *what*? ;-) Whatever you think I was thinking about then, I didn't make the decision (or lobby for a specific outcome). But what you believe is up to you. > > I enjoy choice and options when they bring a true benefit; or at least, > they outweigh the cost. But that isn't always the case - consider: when > we argue about how something should be configured in the CIB XML, do we > implement several ways, just because we can? No? Would you merge them? > Why not? Where the cases where we did the good or bad ideas, from an > admin's point of view? ... Ah. > > You don't see my complaining about corosync 2.x changes relative to 1.4. > Or cman. Fencing improvements. Plugin, MCP, etc. Dropping openais. Or > many other changes. I didn't even mind heartbeat versus corosync as > much; happens largely on the backend. Sure, these all bring technical > challenges on update, but such is life. How often do you see me go up > the walls about something? > > I have spent a year of said life digging into the various costs and > benefits of concurrent open source developments. I realize > forking/splitting code is one of the freedoms we are granted. And that > there are scenarios where this is really a good idea, yes. Is this one > of them? > > I have a very specific issue with crmsh versus pcs, because I think this > hits the community More than having 5 different "pacemaker/corosync/openais" stacks? Really? How much does it matter how resources are configured if people can't even get the thing installed? And yes, I fully acknowledge my part in creating _some_ of that mess. If I knew then what I knew now, I never would have created that stupid custom corosync plugin. Or pingd for that matter. Or failure-stickiness. Sometimes we're just not smart enough at the time to come up with the "right" solution. > (forget about RHEL and SLE HA for a moment, but they > are of course also affected) exactly at the spot where it hurts most, > and where "choice" has a high potential to be detrimental. (The only > other place I could imagine that would get me as riled up would be the > RA interface.) > > I'm being this painful and annoying because I am convinced this will > hurt the project(s)/community, badly. And I'm not even talking > duplicated effort, though that sucks too. And worse, the users; those > who write howtos; the admins; those who try to read them and apply > them to their systems ... Significantly hurt. > > I would go as far as the, possibly slightly stretched, position that it > hurts the entire HA on Linux in the Data Center story in comparison to > other proprietary HA solutions. Imagine, just for a moment, Veritas > having an entirely different management front-end on RHEL than on > SLES. Or changing it completely from version 5 to 6. > > Is it alarmist? Go talk to a few users, administrators, and consultants. Believe it or not, Red Hat has a few of those too. > Decide for yourself. > > > Regards, > Lars > > -- > Architect Storage/HA > SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, > HRB 21284 (AG Nürnberg) > "Experience is the name everyone gives to their mistakes." -- Oscar Wilde > > _______________________________________________ > 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
