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

[Lars Marowsky-Bree]

On 2007-02-22T08:21:02, Alan Robertson <alanr at unix.sh> wrote:

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

They do imply different concepts, though. They _are_ complex objects,
and you forgot master_slave in that list. yes, they could of course all
be lumped together in a single big option rich class, but I'm not too
happy with the idea.

> 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

interleave and order options exist.

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

I disagree strongly with this from a design point of view. You can
already have groups and make them depend on eachother.

What we need is more powerful admin tools which more easily allow you to
affect several resource elements at once, not more weird stuff in the
engine.

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

They also have the elements of the group.

Clones are different from groups in that they expand the objects
contained within (you _can_ clone groups) into several related objects.

It doesn't make sense, IMHO, to lump these together. They are also
handled rather differently internally.

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

No, it does not. The purpose of group objects is convenience for users
transitioning from other software.

The purpose of clones is to add flexibility and provide an abstract
object which is instantiated several times.

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

True. If you did that, and cloned a group, you'd essentially end up with
a group.

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

Indeed. You can add the clone property to groups by nesting groups
inside clones. Amazing, isn't it.

(Which is equivalent to creating a number of clones and creating the
appropriate set of dependencies between them.)

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

I remain unconvinced. 

The current design is based on the assumption that the resources section
contains the objects, and that the relations among them are separately
specified. (That design _is_ reasonably coherent, except for the groups,
which were added as a convenience.)

The idea has always been to shift "convenience" into the adminstrative
tools, which allowed these to be more easily managed.

I object to shift even more complexity into the backend. I agree we need
to make those operations you describe more readily possible, but they
belong into the frontends.

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

Which is exactly the point. The backend was meant to be "simple" (which
we arguably already failed at).


Even if you want to keep this open anyway, I personally think other
issues have higher priority. Including the better GUI/CLI and fixing the
issues with our membership/messaging layers.


Regards,
	Lars

-- 
Teamlead Kernel, SuSE Labs, Research and Development
SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde