>>> Ken Gaillot schrieb am 17.01.2018 um 17:04 in
>>> Nachricht
<1516205099.5103.3.ca...@redhat.com>:
> On Wed, 2018-01-17 at 08:32 +0100, Ulrich Windl wrote:
>> > > > Ken Gaillot schrieb am 16.01.2018 um
>> > > > 23:33 in Nachricht
>>
>> <1516142036.5604.3.ca...@redhat.com>:
>> > As we look
On 15.01.2018 17:51, Ken Gaillot wrote:
> Currently, Pacemaker will use the same detail log as corosync if one is
> specified (as "logfile:" in the "logging {...}" section of
> corosync.conf).
So far I've never dealt with the logging config of Pacemaker but isn't
it possible to configure the log-f
On Thu, 2017-12-07 at 07:33 +0300, Andrei Borzenkov wrote:
> 07.12.2017 00:28, Klaus Wenninger пишет:
> > On 12/06/2017 08:03 PM, Ken Gaillot wrote:
> > > On Sun, 2017-12-03 at 14:03 +0300, Andrei Borzenkov wrote:
> > > > I assumed that with corosync 2.x quorum is maintained by
> > > > corosync and
On Wed, 2018-01-17 at 19:59 +0100, Kristoffer Grönlund wrote:
> Ken Gaillot writes:
>
> >
> > I can see the point, but I do like having separate.
> >
> > A clone with a single instance is not identical to a primitive.
> > Think
> > of building a cluster, starting with one node, and configuring
Ken Gaillot writes:
>
> I can see the point, but I do like having separate.
>
> A clone with a single instance is not identical to a primitive. Think
> of building a cluster, starting with one node, and configuring a clone
> -- it has only one instance, but you wouldn't expect it to show up as a
On Wed, 2018-01-17 at 11:19 +0100, Kristoffer Grönlund wrote:
> Ken Gaillot writes:
>
> >
> > For Pacemaker 2, I'd like to replace the resource type
> > with
> > . (The old syntax would be transparently
> > upgraded to the new one.) The role names themselves are not likely
> > to
> > be changed
On Wed, 2018-01-17 at 11:20 -0500, Doug Cahill wrote:
> Thank you Ken for the feedback on this. That doc was exactly what I
> was looking for but missed it in my searches. I did some testing
> with
> using "crm configure property maintenance-mode=true" and my upgrade
> from 1.1.17 to 1.1.18 worke
Thank you Ken for the feedback on this. That doc was exactly what I
was looking for but missed it in my searches. I did some testing with
using "crm configure property maintenance-mode=true" and my upgrade
from 1.1.17 to 1.1.18 worked in my test environment.
Good info on the 1.1.18 regression fi
On Wed, 2018-01-17 at 08:32 +0100, Ulrich Windl wrote:
> > > > Ken Gaillot schrieb am 16.01.2018 um
> > > > 23:33 in Nachricht
>
> <1516142036.5604.3.ca...@redhat.com>:
> > As we look to release Pacemaker 2.0 and (separately) update the OCF
> > standard, this is a good time to revisit the termino
Ken Gaillot writes:
>
> For Pacemaker 2, I'd like to replace the resource type with
> . (The old syntax would be transparently
> upgraded to the new one.) The role names themselves are not likely to
> be changed in that time frame, as they are used in more external pieces
> such as notification
Ulrich Windl wrote:
Ken Gaillot schrieb am 16.01.2018 um 23:33 in Nachricht
<1516142036.5604.3.ca...@redhat.com>:
As we look to release Pacemaker 2.0 and (separately) update the OCF
standard, this is a good time to revisit the terminology and syntax we
use for master/slave resources.
I think
FWIW, bellow my opinion about this
On Tue, 16 Jan 2018 16:33:56 -0600
Ken Gaillot wrote:
[...]
> I think the term "stateful resource" is a better substitute for
> "master/slave resource". That would mainly be a documentation change.
+1
> A bigger question is what to call the two roles. "Master"
Digimer wrote:
On 2018-01-16 05:33 PM, Ken Gaillot wrote:
As we look to release Pacemaker 2.0 and (separately) update the OCF
standard, this is a good time to revisit the terminology and syntax we
use for master/slave resources.
I think the term "stateful resource" is a better substitute for
"
13 matches
Mail list logo
