Tempest test_trunk_subport_lifecycle may fail as reusing subports won't always work

[Daniel Alvarez]

When a subport becomes up in OVN, networking-ovn will copy the binding host from the parent to it. This will enable Neutron to bind it and therefore it will transition to 'ACTIVE'.
However, when this subport is removed from the trunk and added to a different one (which is bound to a different host), the subport won't ever transition to 'ACTIVE' as the original binding info wasn't cleaned up and OVN will never set the port as 'up'.

This is exactly what test_trunk_subport_lifecycle exercises:

- Creates server1 and server2 with one trunk each
- Assigns subports to trunk in server1
- Verifies that subports and trunks are all ACTIVE
- Removes subports from trunk in server1
- Assigns subports to trunk in server2
- Verifies that subports and trunks are all ACTIVE

This last verification won't succeed if server1 and server2 are bound to different hosts as the subport will retain the old binding information but ovn-controller won't bind it to the right chassis.

The solution is to clear the binding host info when the port goes down.

[Daniel Alvarez (dalvarezs)]

The reason why this is not failing in our gate is because the subport is moved to a different trunk but that trunk is in the same node as we're not running multinode jobs.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/558844

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/558844
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=011dfac87f290948963f7049d8b24a2fd9dfcaf4
Submitter: Zuul
Branch: master

commit 011dfac87f290948963f7049d8b24a2fd9dfcaf4
Author: Daniel Alvarez <email address hidden>
Date: Wed Apr 4 16:50:44 2018 +0200

    Clear binding:host_id when a subport is removed from a trunk

    In networking-ovn we set the binding:host_id of a subport to its
    parent's. However, when we remove the subport, that info remains there
    so if that port would be reused on a trunk which is on a different host,
    it will not get bound to the Chassis by ovn-controller, thus it won't
    transition to 'up' and never become ACTIVE in Neutron. Tempest test
    test_trunk_subport_lifecycle exercises this but the failure doesn't show
    up in the gate since both servers are spawned in the same host (we don't
    have multinode jobs in the gate).

    This patch clears up the host_id when the subport is removed from its
    trunk.

    Closes-Bug: #1761194
    Signed-off-by: Daniel Alvarez <email address hidden>
    Change-Id: Iea31cb3dd418e086c43a797236c4b71d432422f7

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/networking-ovn 5.0.0.0b1 development milestone.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/queens
Review: https://review.openstack.org/563529

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/563529
Committed: https://git.openstack.org/cgit/openstack/networking-ovn/commit/?id=e69c768a3d2f38c140bf3d9228741cba7b08a6c5
Submitter: Zuul
Branch: stable/queens

commit e69c768a3d2f38c140bf3d9228741cba7b08a6c5
Author: Daniel Alvarez <email address hidden>
Date: Wed Apr 4 16:50:44 2018 +0200

    Clear binding:host_id when a subport is removed from a trunk

    In networking-ovn we set the binding:host_id of a subport to its
    parent's. However, when we remove the subport, that info remains there
    so if that port would be reused on a trunk which is on a different host,
    it will not get bound to the Chassis by ovn-controller, thus it won't
    transition to 'up' and never become ACTIVE in Neutron. Tempest test
    test_trunk_subport_lifecycle exercises this but the failure doesn't show
    up in the gate since both servers are spawned in the same host (we don't
    have multinode jobs in the gate).

    This patch clears up the host_id when the subport is removed from its
    trunk.

    Closes-Bug: #1761194
    Signed-off-by: Daniel Alvarez <email address hidden>
    Change-Id: Iea31cb3dd418e086c43a797236c4b71d432422f7
    (cherry picked from commit 011dfac87f290948963f7049d8b24a2fd9dfcaf4)

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/networking-ovn 4.0.1 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/networking-ovn 4.0.2 release.

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/networking-ovn 4.0.3 release.