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? > 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. 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? > 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?) > - Create/Remove resource groups Why is it "resource create", but "resource group add"? > - Set most pacemaker configuration options How do you enumerate which ones are available? > - 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. 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. 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. 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. Cheers, Florian _______________________________________________ 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
