On Wed, 18 Dec 2013 21:21:32 +0100 (CET)
Rainer Brestan rainer.bres...@gmx.net wrote:
What i really miss in crmsh is the possibility to specify resource
parameters which are different on different nodes, so the parameter
is node dependant. In XML syntax this is existing, Andrew gave me the
18.12.2013 23:21, Rainer Brestan wrote:
Hi Lars,
maybe a little off topic.
What i really miss in crmsh is the possibility to specify resource
parameters which are different on different nodes, so the parameter is
node dependant.
In XML syntax this is existing, Andrew gave me the hint as
On 2013-12-13T10:16:41, Kristoffer Grönlund kgronl...@suse.com wrote:
Lars (lmb) suggested that we might switch to using the { } - brackets
around resource sets everywhere for consistency. My only concern with
that would be that it would be a breaking change to the previous crmsh
syntax.
Hi,
Just thought that I was missing in location, something like: node=any :)
___
Pacemaker mailing list: Pacemaker@oss.clusterlabs.org
http://oss.clusterlabs.org/mailman/listinfo/pacemaker
Project Home: http://www.clusterlabs.org
Getting started:
Am Freitag, 13. Dezember 2013, 10:25:48 schrieb Lars Marowsky-Bree:
On 2013-12-13T10:16:41, Kristoffer Grönlund kgronl...@suse.com wrote:
Lars (lmb) suggested that we might switch to using the { } - brackets
around resource sets everywhere for consistency. My only concern with
that would be
On 2013-12-13T13:51:27, Andrey Groshev gre...@yandex.ru wrote:
Just thought that I was missing in location, something like: node=any :)
Can you describe what this is supposed to achieve?
any is the default for symmetric clusters anyway.
Regards,
Lars
--
Architect Storage/HA
SUSE LINUX
On Fri, 13 Dec 2013 10:55:32 +0100
Michael Schwartzkopff m...@sys4.de wrote:
Order for colocations and order constraints: Please don't do it.
Everybody got use to the ordering as it is now. It also makes sense.
Please remember the irritations we had moving from heartbeat 2.0
(with XML,
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
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
On 2013-12-13T13:11:30, Rainer Brestan rainer.bres...@gmx.net wrote:
Please do not merge colocation and order together in a way that only none or
both is present.
This was never the plan.
The idea was to offer an additional construct that provides both
properties, since *most of the time*,
13.12.2013 15:39, Lars Marowsky-Bree wrote:
On 2013-12-13T13:11:30, Rainer Brestan rainer.bres...@gmx.net wrote:
Please do not merge colocation and order together in a way that only none or
both is present.
This was never the plan.
The idea was to offer an additional construct that
On 2013-12-14T01:11:17, Vladislav Bogdanov bub...@hoster-ok.com wrote:
The idea was to offer an additional construct that provides both
properties, since *most of the time*, that's what users want. In the
interest of clarity and brevity in the configuration, this would be
quite useful.
12 matches
Mail list logo
