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.
> 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.) 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*? ;-)
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 (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.
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
