[Linux-HA] Collections: clones and groups oh my!

[Alan Robertson]

This discussion is intended to be a user-model or feature discussion -
the implementation can be discussed after we've discussed the idea and
decided if it makes any sense from a user's conceptual view.  If it
doesn't make conceptual sense, then the implementation discussion is
irrelevant.

We currently have two different kinds of Collections in the CIB - clones
and groups.

And some people would like to have with implied start-after and ordering
dependencies associated with clones.
http://lists.community.tummy.com/pipermail/linux-ha/2007-February/023380.html

I would like to have groups of groups:
http://old.linux-foundation.org/developer_bugzilla/show_bug.cgi?id=1496

And, at the moment we can't do either of these easily.

If stands back a bit from the current user model as described by the DTD
a little bit one can see that both clones and groups are instances of
Collections of Resources.

Groups are a Collection of Resources with the following optional implied
properties:
	start-after-ordering
	colocation dependencies

Clones are a Collection of Resources with the following properties:
	clone-max
	clone-node-max
	(and some others)

If one adds the start-after-ordering and colocation dependencies as
optional properties to clones, then the purpose of groups and clones
becomes roughly equivalent - and Sebastian's problem gets solved.  If
one sets clone-max to 1, then even right now, a clone is very similar to
a group without ordering or colocation.  [I know about notifications,
but they're only used if the resource wants to hear them].

If one were to add the clone properties to groups - and defaults
clone-max to 1, then the two constructs are also roughly equivalent from
that perspective.

And, syntactically they're also quite similar.

So, from this theoretical and conceptual and user-model point of view,
and from a syntactic point of view, one could imagine making the
distinction between groups and clones simply being the default values of
these various properties.

If one adds to that the idea that a Collection can contain any Resource,
whether it be a PrimitiveResource or a Clone or a Group (as per bug
1496), then one has a very straightforward user model with fewer odd
corners and exceptions in it.

There are no new capabilities being added by these user model
simplifications.  Everything you can do with this can be done manually -
but with more pain and possibility of error, and it would be completely
backwards compatible with older versions of the DTD.

Many times a more general model tends to create easier-to-maintain code
(in the long term), providing it isn't _too_ general and doesn't add too
many many features.  In this case it doesn't add new basic capabilities,
it just makes them available in a simpler-to-construct and less
surprising package.

No doubt I've missed something in my thinking (besides implementation
details).

Thoughts?


-- 
    Alan Robertson <alanr at unix.sh>

"Openness is the foundation and preservative of friendship...  Let me
claim from you at all times your undisguised opinions." - William
Wilberforce