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

[Chris Feist]

On 06/01/12 09:56, Florian Haas 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.

Absolutely, I'm not taking any of the criticism personally and I do appreciate 
the feedback.

>> 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?

We needed a unified CLI that would configure corosync's as well as pacemaker's 
(and eventually the dlm for GFS2).  We also needed that CLI to tightly integrate 
with our GUI efforts and to be able to remotely connect to the GUI.  As a by 
product, my goal was to make it extremely easy to get up and running, while 
still allowing power users to do configure all the options.

>> 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?

pcs still has a ways to go, but there will be an option to print out the 
available resource (and stonith) agents as well as their required/optional 
arguments.  I'm not currently planning on having a shell mode for pcs (which is 
what I meant by not adding interactivity).

>> 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"?

I'm still working out the exact syntax, so there will be a few inconsistencies, 
but I may change resource 'create' to 'add'.  My thinking was that you create 
resources, but you add them to a resource group.

>> - Set most pacemaker configuration options
>
> How do you enumerate which ones are available?

There will be an option to list available options, but I'm not there yet.

>> - 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?

This code is still in development as it depends on code in the GUI to transfer 
configuration files around the cluster.  As soon as I have a somewhat stable 
version of this to test (I'm shooting for 2-3 weeks) I'll notify the list, so 
you can take a look at it.

>> 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.

I believe the CRM shell is still in Fedora 17, but I'm not sure what its status 
is for Fedora 18 and beyond.  I'm pretty sure that if it isn't included as part 
of pacemaker that it would be accepted as a separate package.

I'm also trying to make sure that pcs doesn't use any magic to do configuration, 
so if you have a cluster that was configured with pcs there won't be any issue 
with reading/modifying that same cluster configuration with crm.  It's just an 
additional option to hopefully simplify configuration.

> 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 at 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