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

[Florian Haas]

On Mon, Jun 4, 2012 at 3:21 AM, Andrew Beekhof <andrew at beekhof.net> wrote:
> 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.

Andrew, thanks for confirming. :)

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

I don't disagree with the importance of some of those, but none of
them look like a compelling reason to write a new one from scratch.

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

That is true, but having done a bash completion thingy myself before,
I can tell you it's quite a bit of effort. Unless, that is, the tool
has a generic hook that completion systems can tie into, like what
Mercurial does (iirc).

Note that something taking a lot of effort doesn't disqualify it, but
creating a lot of effort just to match functionality that something
else already has -- that's questionable.

The crm shell is actually not just about simple tab completion, it's
about tab completion with the added benefits of providing
documentation interactively, and to the best of my knowledge that's
something you can't do in bash completion. Other completion systems I
don't know.

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

Oh, am I?

> Are you seriously claiming interactivity is the only way to discover
> information about a program?

Yeah, we all know how attentively people read man pages.

> Quick, someone tell the iproute developers that no-one can add an IP
> address because 'ip help' and 'ip addr help' aren't interactive!

Remind me how _that_ comment isn't silly?

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

See below on that comment.

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

Well you add and create one in one fell swoop (which is OK -- makes no
sense to have an empty group), but it might still be a good idea in
terms of POLA to add "create", even if all it does is check that the
group doesn't already exist, and then hand off to "add".

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

You'll hate me again for saying this, but by having this discussion
we're already smack in the middle of duplicating effort. For something
that's solved in an existing tool.

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

Possible, but given the fact that the then-available open-source
cluster resource manager on Linux trailed far behind what was
available on other platforms or commercially, there was lots of
tangible improvement that Pacemaker (well, the crm initially)
provided. It just had a usability problem for years.

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

No disagreement. I maintain that I have a right to voice my opinion about it.

> Personally I'm hoping a little friendly competition will result in
> both projects finding new ways to improve usability.

Much of which will potentially be lost in conflicting documentation on
how to do X, depending on distro, tools installed, etc. You really
think that choice is good in each and every way? Remember how many
discussions we've had, and are still having, on this list and
elsewhere about ver:0, ver:1, cman and friends? I am still under the
impression that we're attempting to unify the stack, and still every
distro seems to run off on its own One Right Way of doing things.

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

Is "moving on" meant to imply "move away from confusing users"? Then yes please.

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

Insinuating that I'm not respectful of his right to continue is
exactly what, if not a straw man?

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

I would hope someone does. I've been through that process before and I
currently really don't have the bandwidth to spend a month on it.

Cheers,
Florian