[Deepsea-users] timeout disengage.safety

Robert Grosschopff Robert.Grosschopff at suse.com
Wed Aug 8 06:03:24 MDT 2018

Hi *,

problem is solved now. It was a network issue.
public network :
cluster network :

The admin node had a second IP 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.


-----Original Message-----
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?
    > Thx
    > Alan
    Joshua Schmid
    Software Engineer
    SUSE Enterprise Storage
    Deepsea-users mailing list
    Deepsea-users at lists.suse.com

More information about the Deepsea-users mailing list