On 05/12/2012, at 4:05 AM, Lars Marowsky-Bree <l...@suse.com> wrote:
> 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. I would very much like to ditch groups for sets, but there are still some things I just can't get to work without the group pseudo resource. _______________________________________________ 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
