Re: [ClusterLabs] [corosync] Master branch

2016-10-11 Thread Jan Friesse
I've just committed a bit patch to the master branch of corosync - it is now all very experimental, and existing pull requests against master might need to be checked. This starts the work on what will hopefully Thanks Chrissie, nice work. I must highlight "it is now all very experimental". Of

Re: [ClusterLabs] Unfencing cause resource restarts

2016-10-11 Thread Pavel Levshin
11.10.2016 17:40, Ken Gaillot: On 10/11/2016 07:06 AM, Pavel Levshin wrote: Hi! In continuation of prevoius mails, now I have more complex setup. Our hardware are capable of two STONITH methods: ILO and SCSI persistent reservations on shared storage. First method works fine, nevertheless, some

Re: [ClusterLabs] Unfencing cause resource restarts

2016-10-11 Thread Ken Gaillot
On 10/11/2016 07:06 AM, Pavel Levshin wrote: > Hi! > > > In continuation of prevoius mails, now I have more complex setup. Our > hardware are capable of two STONITH methods: ILO and SCSI persistent > reservations on shared storage. First method works fine, nevertheless, > sometimes in the past we

Re: [ClusterLabs] [corosync] Master branch

2016-10-11 Thread Christine Caulfield
On 11/10/16 12:07, Dennis Jacobfeuerborn wrote: > On 11.10.2016 12:42, Christine Caulfield wrote: >> I've just committed a bit patch to the master branch of corosync - it is >> now all very experimental, and existing pull requests against master >> might need to be checked. This starts the work on

[ClusterLabs] Unfencing cause resource restarts

2016-10-11 Thread Pavel Levshin
Hi! In continuation of prevoius mails, now I have more complex setup. Our hardware are capable of two STONITH methods: ILO and SCSI persistent reservations on shared storage. First method works fine, nevertheless, sometimes in the past we faced problems with inaccessible ILO devices or somet

Re: [ClusterLabs] [corosync] Master branch

2016-10-11 Thread Dennis Jacobfeuerborn
On 11.10.2016 12:42, Christine Caulfield wrote: > I've just committed a bit patch to the master branch of corosync - it is > now all very experimental, and existing pull requests against master > might need to be checked. This starts the work on what will hopefully > become corosync 3.0 > > The co

[ClusterLabs] [corosync] Master branch

2016-10-11 Thread Christine Caulfield
I've just committed a bit patch to the master branch of corosync - it is now all very experimental, and existing pull requests against master might need to be checked. This starts the work on what will hopefully become corosync 3.0 The commit is to make Kronosnet the new, default, transport for co

Re: [ClusterLabs] Antw: Re: Antw: Re: Antw: Re: When the DC crmd is frozen, cluster decisions are delayed infinitely

2016-10-11 Thread renayama19661014
Hi Klaus, Thank you for comment. I make the patch which is prototype using WD service. Please wait a little. Best Regards, Hideo Yamauchi. - Original Message - > From: Klaus Wenninger > To: users@clusterlabs.org > Cc: > Date: 2016/10/10, Mon 21:03 > Subject: Re: [ClusterLabs] Antw

Re: [ClusterLabs] Antw: Re: Establishing Timeouts

2016-10-11 Thread Christine Caulfield
On 11/10/16 08:22, Vladislav Bogdanov wrote: > 11.10.2016 09:31, Ulrich Windl wrote: > Klaus Wenninger schrieb am 10.10.2016 um > 20:04 in >> Nachricht <936e4d4b-df5c-246d-4552-5678653b3...@redhat.com>: >>> On 10/10/2016 06:58 PM, Eric Robinson wrote: Thanks for the clarification. So

Re: [ClusterLabs] Establishing Timeouts

2016-10-11 Thread Christine Caulfield
On 10/10/16 19:35, Eric Robinson wrote: > Basically, when we turn off a switch, I want to keep the cluster from failing > over before Linux bonding has had a chance to recover. > > I'm mostly interested in prventing false-positive cluster failovers that > might occur during manual network maint

Re: [ClusterLabs] Antw: Re: Establishing Timeouts

2016-10-11 Thread Vladislav Bogdanov
11.10.2016 09:31, Ulrich Windl wrote: Klaus Wenninger schrieb am 10.10.2016 um 20:04 in Nachricht <936e4d4b-df5c-246d-4552-5678653b3...@redhat.com>: On 10/10/2016 06:58 PM, Eric Robinson wrote: Thanks for the clarification. So what's the easiest way to ensure that the cluster waits a desired