[Pacemaker] Dependency Trees

[Andrew Beekhof]

On Thu, Feb 21, 2013 at 1:51 PM, Donald Stahl <don at blacksun.org> wrote:
>> shouldn't be too hard
> Whenever you make something idiot proof, the universe invents a bigger idiot.

:)

> I'm that idiot I guess.

Have you seen clusters from scratch?
Its a pretty good starting point.

>> use colocation constraints for the things that need to run on the same node
> Except colocation resources also include order unless you specifically
> tell it that the items are not sequential (At least in my testing).

Sort of.
If you say "colocate A with B" and there is nowhere B is allowed to
run, then A wont be allowed to run either.
But once the cluster has figured out where they go, it doesn't stop
them being started in parallel.

>
> Furthermore- you can't have a colocation resource of colocation
> resources. Nor can you have a group of colocation resources.
>
> You also can't have a group of groups.

Don't use groups.  Just define the individual resources and the
relationships between them.

>
> I'd love to be able to create a group called "filesystem" that
> includes all of the file system mounts I have- and then be able to
> create a group that includes the listener, the IP, and the filesystem
> group- except you can't have a group of groups. And if I try to create
> a group with the listener, the IP and the individual filesystems- then
> I can't create another group that also includes those filesystems
> because they're already in a group.
>
> I realize this "shouldn't be too hard" but I honestly can't come up
> with a way to replicate the VCS behavior with pacemaker. I can create
> something that roughly approximates it- but it isn't the same.
>
> It's possible pacemaker can't articulate these ideas- and if so-
> that's fine. I'll work around it.

I think part of the problem is that the requirements are somewhat in
conflict with each other.
On the one hand, you say OraListener1 and OraInstance1 need to be on
the same node, but on the other you say they can start/stop
individually.

I hadn't read that part so closely when I said "shouldn't be too hard"
and indeed that is hard for us to express.
In Pacemaker, either A needs B or it doesn't.

Other than that, you seem to want:

order OraInstance1 OraBin1
order OraInstance1 OraData1

order OraListener1 OraBin1
order OraListener1 OraData1
order OraListener1 OraIP1

Do OraInstance1/OraListener1 need to live on the same host as OraBin1/OraData1 ?
If so, you can get the behaviour you're after by adding something like:

colocate OraInstance1 OraBin1
colocate OraListener1 OraBin1
colocate OraBin1 OraData1

So OraInstance1 and OraListener1 can go up/down individually but
always on the same host as OraBin1/OraData1.
Also, if OraBin1 or OraData1 go down they'll take OraInstance1 and
OraListener1 with them.

Is that close?

> I think the more likely explanation
> is that I don't fully understand the limitations and use of
> colocations, orders and groups. If someone can point me at a thorough
> explanation of when you would choose a group over a colocation with an
> order and/or the specific limitations of each- I would be grateful.
>
> -Don
>
> _______________________________________________
> 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