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

[Lars Marowsky-Bree]

On 2012-05-31T18:40:19, Chris Feist <cfeist at redhat.com> wrote:

Hi Chris,

this is certainly a very interesting undertaking.

Like Florian, I am a bit worried about how exactly this differs from the
crm shell we already have - that is not to say I'm opposed to it, but
I'd like to understand this better, given that we'll eventually have to
explain the different goals and distinctions to our user base ;-)

I am very open to this being a valuable addition to the fold, and thank
you for contributing to the eco system.

Still, I admit to wanting to understand why the goals could not be met
by enhancing the existing tools. It is quite possible that there are
excellent reasons for that, in which case I hope to understand them
better.

> The emphasis in PCS differs somewhat from the existing shell:
> - Configure the complete cluster (corosync plus pacemaker) from scratch

That is clearly important, and a short-coming of the existing shell. It
is indeed very CIB-centric (for historical reasons), but I don't see how
this couldn't have been added via a "corosync" toplevel menu or such.

> - Emphasis is on modification not display

But to modify one needs to know what is already there, right? So
"display" is still important.

> - Avoid XML round-tripping

I'm not quite sure what this means. That the existing CRM shell's
configuration mode converts from XML to shell syntax and vice-versa? I
agree that this is a significant performance penalty to pay, but not all
CRM shell commands do this, and possibly this could be enhanced further.

(For example, "crm configure primitive ..." could directly go to a CIB
insert and parse that, etc. So it's possible, just not currently done;
and doing it would benefit all existing tools and scripts, including
hawk etc.)

> - Syntax won't be restricted to concepts from the underlying XML (which
>   should make it easier to configure simple clusters)

I'm not sure this is something I understand; do you mean stuff like
wizards & workflows? There is very rudimentary support for this, and
hawk has some more powerful stuff, but definitely a good direction to
explore and invest further in.

Again, not necessarily a reason for an entirely new approach - since you
still need the ability to work with the CIB heavily.

> - Provide the ability to remotely configure corosync, start/stop cluster and
>   get status.

Sure, this is important. But couldn't this be added to the shell as
well? The history explorer does something similar by leveraging pssh to
work on all cluster nodes, and this could be reused/improved.

> In addition, it will do much of the back-end work for a new GUI
> being developed, also by Red Hat (pcs-gui).

Oh, yet another GUI ;-) I look forward to seeing how this differs.

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

So I assume it'd be one-on-one commandline invocation and/or a batch
mode? (The latter would be quite useful for scripting.)

crm's interactive mode is something that I find personally quite
worthwhile, though. For stuff like the history explorer, the "simulator"
(crm_test etc), working through various configuration steps etc. But I
can see that this probably depends on how you use it.

> You can view a sample pcs session to get a preliminary view of how
> pcs will work  - https://gist.github.com/2697640

Okay, I can see how this is neat, because it also configures corosync.
(Tim has done something similar with the join/bootstrap scripts, that do
stuff like corosync.conf, csync2, etc.) Standardizing that is cool.

But the rest looks like an almost 1:1 mapping of crm commands to a
slightly different syntax.

Admittedly, crm has accrued some syntax oddities over the years - that
is not meant as disrespect to Dejan at all, since the same is true of
the CIB and any other tool that has evolved! - but I really would like
to see an example of how this differs in ways that are more
significant; even if just as a mock-up.

Again, let me stress I am *not* opposed to a new toolset. I am worried
about the trade-off between user confusion and benefit to users; if it
is an incremental enhancement, I think it may be worth implementing it
as such rather than as a new tool.


Regards,
    Lars

-- 
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB 21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde