On Sat, Jun 2, 2012 at 12:56 AM, Florian Haas <flor...@hastexo.com> wrote: > On Fri, Jun 1, 2012 at 1:40 AM, Chris Feist <cfe...@redhat.com> wrote: >> I'd like to announce the existence of the "Pacemaker/Corosync configuration >> system", PCS. > > Be warned, I will surely catch flak for what I'm about to say. Nothing > of this should be understood in a personal way; my critique is about > the work not the artist. > >> The emphasis in PCS differs somewhat from the existing shell: > > Before you get into where it differs in emphasis, can you explain why > we need another shell?
Uh, because the world isn't black & white and people find different things important? Like, perhaps, some of the things Chris listed. > >> PCS will continue the tradition of having a regression test suite and >> discoverable 'ip'-like hierarchical "menu" structure, however unlike the >> shell we may end up not adding interactivity. > > Strangely enough, if I were to name one feature as the most useful in > the existing shell, it's its interactivity. Personally I disagree. Mostly what I see people using is tab completion, which is not interactivity and even if considered crucial, doesn't need to be baked into the tool itself. > How do you envision people configuring, say, an IPaddr2 resource when > they don't remember the parameter names, or whether a specific > parameter is optional or required? Or even the resource agent name? Now you're just being silly. Are you seriously claiming interactivity is the only way to discover information about a program? Quick, someone tell the iproute developers that no-one can add an IP address because 'ip help' and 'ip addr help' aren't interactive! >> Both projects are far from complete, but so far PCS can: >> - Create corosync/pacemaker clusters from scratch >> - Add simple resources and add constraints > > If I were a new user, I'd probably be unable to create even a simple > resource with this, for the reason given above. But I will concede > that at its current state it's probably unfair to expect that new > users are able to use this. (The existing shell is actually usable for > newcomers, even though it's not perfect. Why to we need a new shell > again?) To see how many straw men you could construct. > >> - Create/Remove resource groups > > Why is it "resource create", but "resource group add"? I /think/ its because you're adding a resource to an existing group. >> - Set most pacemaker configuration options > > How do you enumerate which ones are available? Valid question > >> - Start/Stop pacemaker/corosync >> - Get basic cluster status > >> I'm currently working on getting PCS fully functional with Fedora 17 (and it >> should work with other distributions based on corosync 2.0, pacemaker 1.1 >> and systemd). >> >> I'm hoping to have a fairly complete version of PCS for the Fedora 17 >> release (or very shortly thereafter) and a functioning version of pcs-gui >> (which includes the ability to remotely start/stop nodes and set corosync >> config) by the Fedora 18 release. >> >> The code for both projects is currently hosted on github >> (https://github.com/feist/pcs & https://github.com/feist/pcs-gui) >> >> You can view a sample pcs session to get a preliminary view of how pcs will >> work - https://gist.github.com/2697640 > > Any reason why the gist doesn't use "pcs cluster sync", which as per > "pcs cluster --help" would sync the Corosync config across nodes? > >> Comments and contributions are welcome. > > I'm sorry, and I really don't mean this personally, but I just don't > get the point. Plenty of people didn't see the point of Pacemaker either. And I don't recall anyone saying "they hate the existing [resource manager] and this effort solves all their problems" about the first few years Pacemaker development. Open source has a long and glorious history of people saying "I'm going to try and do it this way" and Chris has every right to try something different. Personally I'm hoping a little friendly competition will result in both projects finding new ways to improve usability. > I fail to see significant advantages that would justify > the duplication of effort versus the existing shell, not only in terms > of development, but also documentation, training, educating users, > etc. We've confused users aplenty in the past. Now we have a shell > that while not perfect, works well, has a reasonable degree of > interactivity and self-documentation, and is suitable for general use > (at least in my, never very humble, opinion). I see no reason for it > to be replaced. We get that. Can we move on now? You don't have to like that there is a new shell, but can we concentrate on being constructive about Chris' work (or at least be respectful of his right to continue it) please? > Assuming that this effort means you're planning to kick the existing > crm shell out of Fedora, I think that's a really really bad idea. Actually since its not part of Pacemaker anymore*, someone would need to sponsor it through Fedora's new package process. Anyone is welcome to become a packager and do so. * at the shell author Dejan's request, for those that haven't been following along > > Just my two cents, of course, and if people speak up and say they hate > the existing shell and this effort solves their problems, then I'm all > for choice. But I can't recall hearing that from users. _______________________________________________ Pacemaker mailing list: Pacemaker@oss.clusterlabs.org http://oss.clusterlabs.org/mailman/listinfo/pacemaker Project Home: http://www.clusterlabs.org Getting started: http://www.clusterlabs.org/doc/Cluster_from_Scratch.pdf Bugs: http://bugs.clusterlabs.org
