On Wed, Jul 11, 2018 at 04:31:31PM -0600, Casey & Gina wrote:
> Forgive me for interjecting, but how did you upgrade on Ubuntu? I'm
> frustrated with limitations in 1.1.14 (particularly in PCS so not sure
> if it's relevant), and Ubuntu is ignoring my bug reports, so it would
> be great to
> After I successfully upgraded Pacemaker from 1.1.14 to 1.1.18 and corosync
> from 2.3.35 to 2.4.4 on Ubuntu 14.04 I am trying to repeat the same scenario
> on Ubuntu 16.04.
Forgive me for interjecting, but how did you upgrade on Ubuntu? I'm frustrated
with limitations in 1.1.14
I was able to get this sorted out thanks to Ken's help on IRC. For some
reason, stonith_admin -L did not list the device I'd added until I set
stonith_enabled=true, even though on other clusters this was not necessary. My
process was to ensure that stonith_admin could successfully
Sorry replied too soon.
Since disabling the update-rc.d command I assume the build process creates the
services.
The only problem is that enabling them with systemctl does not work because it
leverage on update-rc.d command that works only if LSB header container at
least one run level.
For
Hi,
I solved the issue (I am not sure to be honest) simply removing the update-rc.d
command.
I noticed I can start the corosync and pacemaker services with:
service corosync start
service pacemaker start
I am not sure if they have been enabled at book (on Docker is not easy to test).
I do not
On Wed, 2018-07-11 at 22:07 +0300, Andrei Borzenkov wrote:
> 11.07.2018 21:01, Salvatore D'angelo пишет:
> > Yes, but doing what you suggested the system find that sysV is
> > installed and try to leverage on update-rc.d scripts and the
> > failure occurs:
>
> Then you built corosync without
On Wed, Jul 11, 2018 at 08:01:46PM +0200, Salvatore D'angelo wrote:
> Yes, but doing what you suggested the system find that sysV is
> installed and try to leverage on update-rc.d scripts and the failure
> occurs:
>
> root@pg1:~# systemctl enable corosync
> corosync.service is not a native
11.07.2018 21:01, Salvatore D'angelo пишет:
> Yes, but doing what you suggested the system find that sysV is installed and
> try to leverage on update-rc.d scripts and the failure occurs:
Then you built corosync without systemd integration. systemd will prefer
native units.
>
> root@pg1:~#
I have a number of clusters in a vmWare ESX environment which have all been set
up following the same steps, unless somehow I did something wrong on some
without realizing it.
The issue I am facing is that on some of the clusters, after adding the STONITH
resource, testing with `stonith_admin
Yes, but doing what you suggested the system find that sysV is installed and
try to leverage on update-rc.d scripts and the failure occurs:
root@pg1:~# systemctl enable corosync
corosync.service is not a native service, redirecting to systemd-sysv-install
Executing
On Wed, 2018-07-11 at 18:43 +0200, Salvatore D'angelo wrote:
> Hi,
>
> Yes that was clear to me, but question is pacemaker install
> /etc/init.d/pacemaker script but its header is not compatible with
> newer system that uses LSB.
> So if pacemaker creates scripts in /etc/init.d it should create
Thank you. It's clear now.
Il Mer 11 Lug 2018, 7:18 PM Andrei Borzenkov ha
scritto:
> 11.07.2018 20:12, Salvatore D'angelo пишет:
> > Does this mean that if STONITH resource p_ston_pg1 even if it runs on
> node pg2 if pacemaker send a signal to it pg1 is powered of and not pg2.
> > Am I
11.07.2018 20:12, Salvatore D'angelo пишет:
> Does this mean that if STONITH resource p_ston_pg1 even if it runs on node
> pg2 if pacemaker send a signal to it pg1 is powered of and not pg2.
> Am I correct?
Yes. Resource will be used to power off whatever hosts are listed in its
pcmk_host_list.
Does this mean that if STONITH resource p_ston_pg1 even if it runs on node pg2
if pacemaker send a signal to it pg1 is powered of and not pg2.
Am I correct?
> On 11 Jul 2018, at 19:10, Andrei Borzenkov wrote:
>
> 11.07.2018 19:44, Salvatore D'angelo пишет:
>> Hi all,
>>
>> in my cluster doing
11.07.2018 19:44, Salvatore D'angelo пишет:
> Hi all,
>
> in my cluster doing cam_mon -1ARrf I noticed my STONITH resources are not
> correctly located:
Actual location of stonith resources does not really matter in up to
date pacemaker. It only determines where resource will be monitored;
Suppose I do the following:
crm configure delete l_ston_pg1
crm configure delete l_ston_pg2
crm configure delete l_ston_pg3
crm configure location l_ston_pg1 p_ston_pg1 inf: pg1
crm configure location l_ston_pg2 p_ston_pg2 inf: pg2
crm configure location l_ston_pg3 p_ston_pg3 inf: pg3
How long
You need to use location l_ston_pg3 p_ston_pg3 inf: pg3, because -inf is
negative.
2018-07-11 18:44 GMT+02:00 Salvatore D'angelo :
> Hi all,
>
> in my cluster doing cam_mon -1ARrf I noticed my STONITH resources are not
> correctly located:
> p_ston_pg1 (stonith:external/ipmi): Started pg2
>
Hi all,
in my cluster doing cam_mon -1ARrf I noticed my STONITH resources are not
correctly located:
p_ston_pg1 (stonith:external/ipmi):Started pg2
p_ston_pg2 (stonith:external/ipmi):Started pg1
p_ston_pg3 (stonith:external/ipmi):Started pg1
I have three
Source code for the final release of Pacemaker version 1.1.19 is
available at:
https://github.com/ClusterLabs/pacemaker/releases/tag/Pacemaker-1.1.19
This is a maintenance release that backports selected fixes and
features from the 2.0.0 version. The 1.1 series is no longer actively
maintained,
Hi,
Yes that was clear to me, but question is pacemaker install
/etc/init.d/pacemaker script but its header is not compatible with newer system
that uses LSB.
So if pacemaker creates scripts in /etc/init.d it should create them so that
they are compatible with OS supported (not sure if Ubuntu
11.07.2018 18:08, Salvatore D'angelo пишет:
> Hi All,
>
> After I successfully upgraded Pacemaker from 1.1.14 to 1.1.18 and corosync
> from 2.3.35 to 2.4.4 on Ubuntu 14.04 I am trying to repeat the same scenario
> on Ubuntu 16.04.
16.04 is using systemd, you need to create systemd unit. I do
Hi All,
After I successfully upgraded Pacemaker from 1.1.14 to 1.1.18 and corosync from
2.3.35 to 2.4.4 on Ubuntu 14.04 I am trying to repeat the same scenario on
Ubuntu 16.04.
As my previous scenario I am using Docker for test purpose before move to Bare
metal.
The scenario worked properly
On Wed, 2018-07-11 at 13:44 +0200, Ulrich Windl wrote:
> > > > Ian Underhill schrieb am 11.07.2018
> > > > um 13:27 in
>
> Nachricht
> :
> > im trying to understand the behaviour of pacemaker when a resource
> > monitor
> > returns OCF_NOT_RUNNING instead of OCF_ERR_GENERIC, and does
> >
Message: 1
Date: Wed, 11 Jul 2018 11:06:56 +0200
From: Klaus Wenninger
To: Cluster Labs - All topics related to open-source clustering
welcomed , Andrei Borzenkov
Subject: Re: [ClusterLabs] What triggers fencing?
Message-ID:
Content-Type: text/plain; charset=utf-8
On 07/11/2018
On Wed, 2018-07-11 at 11:06 +0200, Klaus Wenninger wrote:
> On 07/11/2018 05:48 AM, Andrei Borzenkov wrote:
> > 11.07.2018 05:45, Confidential Company пишет:
> > > Not true, the faster node will kill the slower node first. It is
> > > possible that through misconfiguration, both could die, but
>>> Ian Underhill schrieb am 11.07.2018 um 13:27 in
Nachricht
:
> im trying to understand the behaviour of pacemaker when a resource monitor
> returns OCF_NOT_RUNNING instead of OCF_ERR_GENERIC, and does pacemaker
> really care.
>
> The documentation states that a return code OCF_NOT_RUNNING
im trying to understand the behaviour of pacemaker when a resource monitor
returns OCF_NOT_RUNNING instead of OCF_ERR_GENERIC, and does pacemaker
really care.
The documentation states that a return code OCF_NOT_RUNNING from a monitor
will not result in a stop being called on that resource, as it
On 07/11/2018 05:48 AM, Andrei Borzenkov wrote:
> 11.07.2018 05:45, Confidential Company пишет:
>> Not true, the faster node will kill the slower node first. It is
>> possible that through misconfiguration, both could die, but it's rare
>> and easily avoided with a 'delay="15"' set on the fence
28 matches
Mail list logo
