Open Stack

Yeah, I wasn't thinking when I +2'ed that. There are two use cases for the
pinger, one for ensuring continuous connectivity and one for eventual
connectivity.

I think the revert is okay for a quick fix, but we really need a new
argument to the pinger for strictness to decide which behavior the test is
looking for.

On Aug 4, 2016 11:49 AM, "Brian Haley" <brian.haley at hpe.com> wrote:

> On 08/04/2016 01:36 PM, Armando M. wrote:
>
>> Hi Neutrinos,
>>
>> I have noticed that Liberty seems to be belly up [1]. I wonder if anyone
>> knows
>> anything or has the time to look into it.
>>
>> Many thanks,
>> Armando
>>
>> [1] https://review.openstack.org/#/c/349039/
>>
>
> This could be due to this backport;
>
> https://review.openstack.org/#/c/347062/
>
> Before we were doing 'ping -c 3 -W 1 $IP', which will succeed as long as
> one packet is returned.
>
> Now there is an outer loop that runs 'ping -c 1 -W 1 $IP', so a single
> dropped packet could cause an error.  Since sometimes that first packet
> causes ARP to happen, any delay near the 1-second mark looks like a lost
> packet, but is really just transient and packets 2 and 3 are fine.
>
> I've started a revert and will recheck, but if I'm right an async issue
> like this is hard to reliably reproduce - I had to use iptables directly to
> test my theory about the return code from ping when 1/3 packets were lost.
>
> -Brian
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160804/dfc510d2/attachment.html>