Comment 10 for bug 1755890

Reviewed: https://review.openstack.org/553817
Committed: https://git.openstack.org/cgit/openstack/nova/commit/?id=2e03eae67d7977be2318dfb89be9890fa4ceb440
Submitter: Zuul
Branch: stable/queens

commit 2e03eae67d7977be2318dfb89be9890fa4ceb440
Author: Mohammed Naser <email address hidden>
Date: Wed Mar 14 20:04:29 2018 +0000

    Revert "Refine waiting for vif plug events during _hard_reboot"

    This reverts commit 5a10047f9dd4383f6ec9046d392f26c93f8420d4.

    This gets us back to Ib0cf5d55750f13d0499a570f14024dca551ed4d4
    which was meant to address an issue introduced
    by Id188d48609f3d22d14e16c7f6114291d547a8986.

    So we essentially had three changes:

    1. Hard reboot would blow away volumes and vifs and then wait for the
       vifs to be plugged; this caused a problem for some vif types (
       linuxbridge was reported) because the event never came and we
       timed out.

    2. To workaround that, a second change was made to simply not wait for
       vif plugging events.

    3. Since #2 was a bit heavy-handed for a problem that didn't impact
       openvswitch, another change was made to only wait for non-bridge vif
       types, so we'd wait for OVS.

    But it turns out that opendaylight is an OVS vif type and doesn't send
    events for plugging the vif, only for binding the port (and we don't
    re-bind the port during reboot). There is also a report of this being a
    problem for other types of ports, see
    If209f77cff2de00f694b01b2507c633ec3882c82.

    So rather than try to special-case every possible vif type that could
    be impacted by this, we are simply reverting the change so we no longer
    wait for vif plugged events during hard reboot.

    Note that if we went back to Id188d48609f3d22d14e16c7f6114291d547a8986
    and tweaked that to not unplug/plug the vifs we wouldn't have this
    problem either, and that change was really meant to deal with an
    encrypted volume issue on reboot. But changing that logic is out of the
    scope of this change. Alternatively, we could re-bind the port during
    reboot but that could have other implications, or neutron could put
    something into the port details telling us which vifs will send events
    and which won't, but again that's all outside of the scope of this
    patch.

    Change-Id: Ib3f10706a7191c58909ec1938042ce338df4d499
    Closes-Bug: #1755890