Yep. Some tests are making sure there are no packets lost. Some are making sure that stuff starts working eventually.
On Aug 4, 2016 12:28, "Brian Haley" <brian.ha...@hpe.com> wrote: > On 08/04/2016 03:16 PM, Rick Jones wrote: > >> On 08/04/2016 12:04 PM, Kevin Benton wrote: >> >>> 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. >>> >> >> What situation requires continuous connectivity? >> > > Maybe the test names can answer that: > > test_assert_pings_during_br_int_setup_not_lost() > _test_assert_pings_during_br_phys_setup_not_lost() > > In other cases we want the previous behavior - is that IP alive? It's > probably just best to put the old code back and make a new > assert_async_ping() based on this code. > > -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
