On 2012-12-04T11:45:16, David Vossel <dvos...@redhat.com> wrote:
> I am okay with this constraint option being implemented, as it is the basis
> for this whole concept. When it comes time to make this usable, don't make
> the abstraction people use to configure this relationship live at the crm
> shell... meaning, Don't introduce the idea of a container object in the shell
> which then goes off and explodes the constraint section under the hood.
> Think this through and come up with a plan to represent what is going on at
> the configuration level.
A resource set already is defined in the constraint section, like Yan
said.
That seems to do what you ask for? We have the primitives etc defined in
the resources section and then glue them together in the constraints;
that's as intended. Objects and their relationships.
Is there something you don't like about Yan's proposal? Sorry for asking
a dumb question, but I can't tell from the above what you'd like to see
changed.
How would you make this more "usable"?
Yes, a frontend might decide to render resource sets special (more like
how groups are handled[1]), but I'm not sure I understand what you're
suggesting.
Regards,
Lars
[1] and it'd perhaps even be cleaner if, indeed, we had resource sets
instead of groups, and could reference them as aggregates as well. But
that may be a different discussion.
--
Architect Storage/HA
SUSE LINUX Products GmbH, GF: Jeff Hawn, Jennifer Guild, Felix Imendörffer, HRB
21284 (AG Nürnberg)
"Experience is the name everyone gives to their mistakes." -- Oscar Wilde
_______________________________________________
Pacemaker mailing list: Pacemaker@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
