[Pacemaker] Suggestions/questions for Pacemaker

Andrew Beekhof andrew at beekhof.net
Fri Nov 6 06:56:40 EST 2009


On Fri, Nov 6, 2009 at 12:16 PM, Colin <colin.hch at gmail.com> wrote:
> Hi All,
>
> we are really happy with Pacemaker because we can already express a
> lot of what we need in the configuration, and so far it has been
> performing really well! There are some areas beyond the basics where
> our usage of the cluster suggests some directions for further
> extensions that I would like to put up for discussion -- also because
> some of the issues might already be solved/solvable, or be due to us
> not using the best method to achieve something...
>
> 1) Some of our resources take a long time to start or stop; AFAICS
> from crm_mon, the cluster only knows, or at least: only shows, the
> states "Started" and "Stopped"; it would be nice to see a "Starting",
> "Migrating from/to xxx" and "Stopping" in crm_mon while the RA script
> is running with the corresponding action.

This is already somewhat possible.  There is an option to turn on
these intermediate states which I think the GUI can take advantage of.
It not enabled by default because of the additional messaging overhead
it creates.

>
> 2) If I haven't missed something, there is no possibility to configure
> dependencies on "any of a group"; given a configuration of "resource
> set A has resources A1, A2, ..., An", we would like to say that
> "resource B needs at least any n resources from group A
> up-and-running, and it would be good if they were all up-and-running."
> (The latter is of course already possible with an appropritate
> advisory ordering constraint.)

Nod.  http://developerbugs.linux-foundation.org/show_bug.cgi?id=2007

>
> 3) In order to recover better from [human] error, is there a
> possibility to tell the cluster to _always_ monitor all resources on
> all nodes (rather than only the resources that should be running on
> any given node)? If not...

Well its possible in theory, we've not had much demand for such a
feature though.

>
> 4) Invoking "crm_node -q" yields a text with the result; it would be
> nice to have the result in the return code, too.

good point

>
> (5) The subject of [cluster] resource constaints based on
> [cpu/memory/net/i/o] resource consumption is already being discussed
> on this list.)
>
> 6) The "multiple-active" parameter is documented as having three
> choices, "block" -> do nothing and mark as unmanaged, "stop_only" ->
> stop all instances, "stop_start" -> stop all instances and then start
> one; the first thing that I wanted to configure, but doesn't exist, is
> 'stop all except one instance'.

generally thats not considered safe.
and such a condition should be a very rare occurrence.

> 7) The naming convention for the XML config seems more difficult than
> necessary with the mixed use of underscores and dashes as
> word-separators.

most of the underscores were replaced by dashes with 1.0, the only
underscores that remain were ones we couldn't change for compatibility
reasons.


thanks for your feedback!




More information about the Pacemaker mailing list