Please do not merge colocation and order together in a way that only none or both is present.
Example 1: Resource A communicates with resource B over network but A must run before B.
In this case only order is needed without colocation.
Example 2: Resource A and B share a local directory structure.
In this case they must run on the same node with colocation, but order is not important.
chain A B
does neither fit example 1 nor 2.
It is OK to have chain additional, but dont remove order and/or colocation.
Or chain is extended to allow specify only order or only colocation.
Rainer
Gesendet: Freitag, 13. Dezember 2013 um 11:57 Uhr
Von: "Lars Marowsky-Bree" <l...@suse.com>
An: "The Pacemaker cluster resource manager" <pacemaker@oss.clusterlabs.org>
Betreff: Re: [Pacemaker] crmsh: New syntax for location constraints, suggestions / comments
Von: "Lars Marowsky-Bree" <l...@suse.com>
An: "The Pacemaker cluster resource manager" <pacemaker@oss.clusterlabs.org>
Betreff: Re: [Pacemaker] crmsh: New syntax for location constraints, suggestions / comments
On 2013-12-13T11:46:05, Kristoffer Grönlund <kgronl...@suse.com> wrote:
> This worries me as well, however the current syntax for constraints is
> confusing and error-prone.
Right. At least the { } would make it clear to users that it's now a
resource set and not merely more than 2 in the same sequence.
> It would be great to be able to do something
> to make this easier to use, but exactly what it would be is hard to
> say. Making a change that would silently invert the functionality of
> existing configurations is, I agree, not a good idea. However, maybe it
> would be acceptable if a "version: 2" header is required in the
> document to enable the new syntax?
Yeah. It's one of those "I wish we had done it differently" moments, but
I guess we're stuck here.
But another thing we discussed is hiding ids for dependencies by
default, since except for resource objects they really don't matter in
99% of the cases. That would condense the configuration significantly.
> Yet another option is to come up with some entirely new construct to
> supplement colocation and order which does what I think most people
> intuitively expects by default, which is enforces both colocation and
> ordering, so that 'foo depends on bar' means foo will start after bar,
> and only where bar is running.
chain a b c
(specifying the id or a score would be optional; score would default to
mandatory.)
I'm all in favor. ;-) I'd love it if this had backend support (so pcs
could use it too), but if we can't get it, we may just merge colocation
and order internally to crmsh.
Regards,
Lars
--
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
> This worries me as well, however the current syntax for constraints is
> confusing and error-prone.
Right. At least the { } would make it clear to users that it's now a
resource set and not merely more than 2 in the same sequence.
> It would be great to be able to do something
> to make this easier to use, but exactly what it would be is hard to
> say. Making a change that would silently invert the functionality of
> existing configurations is, I agree, not a good idea. However, maybe it
> would be acceptable if a "version: 2" header is required in the
> document to enable the new syntax?
Yeah. It's one of those "I wish we had done it differently" moments, but
I guess we're stuck here.
But another thing we discussed is hiding ids for dependencies by
default, since except for resource objects they really don't matter in
99% of the cases. That would condense the configuration significantly.
> Yet another option is to come up with some entirely new construct to
> supplement colocation and order which does what I think most people
> intuitively expects by default, which is enforces both colocation and
> ordering, so that 'foo depends on bar' means foo will start after bar,
> and only where bar is running.
chain a b c
(specifying the id or a score would be optional; score would default to
mandatory.)
I'm all in favor. ;-) I'd love it if this had backend support (so pcs
could use it too), but if we can't get it, we may just merge colocation
and order internally to crmsh.
Regards,
Lars
--
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
_______________________________________________ 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
