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

[Serge Dubrouski]

I'd go with idea of adding clone properties to the groups (if it's
possible of course) and getting rid of clones after that. For me it
sounds more logical and closer to other clustering products. In this
case sysadmin will be able to group resources and than add some
constraints to configure nodes where this group is allowed to run,.

On 2/22/07, 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.
>
> 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
> _______________________________________________
> Linux-HA mailing list
> Linux-HA at lists.linux-ha.org
> http://lists.linux-ha.org/mailman/listinfo/linux-ha
> See also: http://linux-ha.org/ReportingProblems
>