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.ha...@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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev