[Pacemaker] Announce: pcs / pcs-gui (Pacemaker/Corosync Configuration System)

[Andrew Beekhof]

On Sat, Jun 2, 2012 at 12:56 AM, Florian Haas <florian at hastexo.com> wrote:
> On Fri, Jun 1, 2012 at 1:40 AM, Chris Feist <cfeist at 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.