Multicast traffic scenario test is failing sometimes on OVN job

[Slawek Kaplonski]

Logstash query: http://logstash.openstack.org/#dashboard/file/logstash.json?query=message%3A%5C%22RuntimeError%3A%20Unregistered%20server%20received%20unexpected%20packet(s).%5C%22

It seems to be happening mostly on wallaby and victoria jobs. It's not very often but happens from time to time.

Example of the failure: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_b66/712474/7/check/neutron-tempest-plugin-scenario-ovn/b661cd4/testr_results.html

Traceback (most recent call last):
  File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/neutron_tempest_plugin/common/utils.py", line 80, in wait_until_true
    eventlet.sleep(sleep)
  File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/eventlet/greenthread.py", line 36, in sleep
    hub.switch()
  File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/eventlet/hubs/hub.py", line 313, in switch
    return self.greenlet.switch()
eventlet.timeout.Timeout: 60 seconds

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/neutron_tempest_plugin/scenario/test_multicast.py", line 274, in test_multicast_between_vms_on_same_network
    self._check_multicast_conectivity(sender=sender, receivers=receivers,
  File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/neutron_tempest_plugin/scenario/test_multicast.py", line 381, in _check_multicast_conectivity
    utils.wait_until_true(
  File "/opt/stack/tempest/.tox/tempest/lib/python3.8/site-packages/neutron_tempest_plugin/common/utils.py", line 84, in wait_until_true
    raise exception
RuntimeError: Unregistered server received unexpected packet(s).

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/792267

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.opendev.org/c/openstack/neutron-tempest-plugin/+/792267
Committed: https://opendev.org/openstack/neutron-tempest-plugin/commit/8de8b99c7052bd7d6205b6aa28e12f1679989dc7
Submitter: "Zuul (22348)"
Branch: master

commit 8de8b99c7052bd7d6205b6aa28e12f1679989dc7
Author: Slawek Kaplonski <email address hidden>
Date: Wed May 19 22:48:33 2021 +0200

    Change way how tcpdump result is checked in multicast test

    In the multicast scenario test, when IGMP snooping is enabled thus
    multicast traffic shouldn't be delivered to the unregistered node.
    To check that this is true, we run tcpdump on the unregistered node
    with filter to catch multicast packets and we assert that any packet
    wasn't captured by tcpdump.
    The problem is that we were expeciting in the actual tcpdump message
    string like:

        '0 packets captured\n0 packets received by filter'

    and that can cause problem as sometimes test is failing due to output
    like:

        '0 packets captured
         3 packets received by filter
         0 packets dropped by kernel'

    Now, according to the tcpdump manpage [1] meaning of the "packets
    received by filter" is like below:

        "the meaning of this depends on the OS on which you're running
        tcpdump, and possibly on the way the OS was configured - if a
        filter was specified on the command line, on some OSes it counts
        packets regardless of whether they were matched by the filter
        expression and, even if they were matched by the filter expression,
        regardless of whether tcpdump has read and processed them yet,
        on other OSes it counts only packets that were matched by
        the filter expression regardless of whether tcpdump has read and
        processed them yet, and on other OSes it counts only packets that
        were matched by the filter expression and were processed by
        tcpdump"

    So to avoid failured to due packets "received by filter", lets just
    match on packets "captured" as in case of this test, when we are using
    "-c1" switch in tcpdump that should be enough.

    [1] https://www.tcpdump.org/manpages/tcpdump.1.html

    Closes-Bug: #1926780
    Change-Id: If36931beecd53c0767a5de5fd01f861961385049

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron-tempest-plugin train-last release.