[ClusterLabs] Hawk vs pcs Web UI

[Ken Gaillot]

On Tue, 2017-11-07 at 10:30 -0600, David Kent wrote:
> Hello,
> 
> What is the difference between Hawk and the pcs Web UI? (Why are
> there two projects, not one? Are they targeting different use cases?)
> 
> I was surprised to see two Web UI implementations under the same
> ClusterLabs umbrella. I assume there's a reason, but I can't find it.
> I'm running Pacemaker on RHEL, so the pcs Web UI works out of the
> box. Hawk looks like it could run on RHEL with a little work building
> from source, but it's been tricky. I'm trying to figure out if it's
> worth the time, and what I might be missing out on.
> 
> Thanks,
> David

The Pacemaker project provides low-level command-line tools
(crm_resource, etc.) and C APIs, that anyone can use to build a front-
end. There are quite a few front-ends available, with the most common
being crm-shell and pcs CLIs and hawk and pcs GUIs.

The reason for that particular split is mainly historical. SuSE, which
adopted Pacemaker first, developed hawk. Red Hat, which adopted
Pacemaker later, developed pcs as an interface that would be more
comfortable to users transitioning from its earlier rgmanager-based
clusters.

There are advantages and disadvantages to having multiple front-ends.
It allows more experimentation and evolution, and tailoring interfaces
to specific use cases. On the other hand, it divides developers'
limited time, and makes how-to's less universal.

At the recent ClusterLabs Summit, we discussed consolidating the back-
ends of hawk/crm-shell/pcs. Since these tools are gaining the ability
to manage other cluster components such as corosync, booth, and sbd,
the Pacemaker back-end alone is not sufficient.

Pcs has its own back-end daemon, pcsd, that runs on all the nodes
(regardless of whether the cluster itself is running), and provides a
python API to manage the various cluster components. It also
coordinates configurations between all nodes in the cluster, and
authenticates pcs users. Most likely, pcsd would become the basis for
the common back-end. This would be mostly invisible to users, but it
would lessen the split in developer time, while still allowing
diversity of front-ends.

Choosing an interface boils down to distro and personal preference. The
easiest option is go with what's available in your OS's repositories
(some, such as Debian, provide both). If you have a strong preference,
you can always build your favorite yourself (which is less of an option
if you are using an enterprise distro and want everything supported).
-- 
Ken Gaillot <kgaillot at redhat.com>