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

[Florian Haas]

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?

> 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