[Deepsea-users] timeout disengage.safety
Robert.Grosschopff at suse.com
Wed Aug 8 06:03:24 MDT 2018
problem is solved now. It was a network issue.
public network : 172.16.2.0/24
cluster network : 172.16.1.0/24
The admin node had a second IP 192.168.168.220 attached to its interface. This caused deepsea to consider that IP as well causing long delays whenever a deepsea command was executed.
'salt test.ping' used only the addresses defined by the public network whereas 'salt-run net.ping' tried to ping from every available IP that is part of the admin node. I suspect that the other deepsea commands do not limit themselves to IPs that are part of the public network only. After removing that left-over IP all commands where _much_ faster.
From: <deepsea-users-bounces at lists.suse.com> on behalf of Joshua Schmid <jschmid at suse.de>
Reply-To: Discussions about the DeepSea management framework for Ceph <deepsea-users at lists.suse.com>
Date: Wednesday, 8. August 2018 at 10:20
To: Discussions about the DeepSea management framework for Ceph <deepsea-users at lists.suse.com>
Subject: Re: [Deepsea-users] timeout disengage.safety
Alan Johnson <alanj at supermicro.com> wrote on Tue, 07. Aug 21:40:
> I see the same thing so what I did was to run the disengage safety in one window and then recall the command prior to the minute elapsing until the cluster started to purge, but I agree one minute is too short - could it be made configurable such as passing an argument?
We have a reference implementation for exactly this.
We can get it in if we find out that this is really needed.
Are you saying that when you run `salt-run disengage.safety; salt-run state.orch ceph.purge`
the purge process is not going through?
SUSE Enterprise Storage
Deepsea-users mailing list
Deepsea-users at lists.suse.com
More information about the Deepsea-users