test_router_add_interface_port may fail due to extra port created

[Shih-Hao Li]

test_router_add_interface_port may fail when an internal metadata network is
created during add_router_interface action.

The potential problem is introduced by Commit 6281fddbcb4c
(https://review.openstack.org/#/c/285048/)
which adds an additional update_port inside add_router_interface()
to update device_id and device_owner on the newly created router port.

The problem could happen when users attach a subnet (for example 10.0.0.0/24)
to a router. During the add_router_interface action, vendor's plugin may
create an internal metadata subnet (such as 169.254.169.252/30) and attach
it to the same router. Since two router ports (10.0.0.1 and 169.254.169.253)
are created during this operation, the extra update_port was called for both
router ports.

Before Commit 6281fddbcb4c, test_router_add_interface_port only saw one
update_port call on 10.0.0.1. After the change, it now sees three
update_port calls, two on 10.0.0.1 and one on 169.254.169.253. Because it
doesn't expect to see the update_port call on port 169.254.169.253 (which is
the last update_port call), the update_port.assert_called_with() fails.

[Shih-Hao Li (shihli)]

A possible solution is posted at

https://review.openstack.org/#/c/355094/

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/355094
Committed: https://git.openstack.org/cgit/openstack/neutron/commit/?id=fadee7a41e88c0081e2a92c4808e845d8ac5df8f
Submitter: Jenkins
Branch: master

commit fadee7a41e88c0081e2a92c4808e845d8ac5df8f
Author: Shih-Hao Li <email address hidden>
Date: Fri Aug 12 14:35:50 2016 -0700

    Fix potential problem in test_router_add_interface_port

    test_router_add_interface_port may fail when an internal metadata
    network is created during add_router_interface action.

    The potential problem is introduced by Commit 6281fddbcb4c
    (https://review.openstack.org/#/c/285048/)
    which adds an additional update_port inside add_router_interface()
    to update device_id and device_owner on the newly created router port.

    The problem could happen when users attach a subnet (for example
    10.0.0.0/24) to a router. During the add_router_interface action,
    vendor's plugin may create an internal metadata subnet (such as
    169.254.169.252/30) and attach it to the same router. Since two
    router ports (10.0.0.1 and 169.254.169.253) are created during this
    operation, the extra update_port was called on both router ports.

    Before Commit 6281fddbcb4c, test_router_add_interface_port only saw
    one update_port call on 10.0.0.1. After the change, it now sees three
    update_port calls, two on 10.0.0.1 and one on 169.254.169.253.
    Because it doesn't expect to see the update_port call on port
    169.254.169.253 (which is the last update_port call),
    the update_port.assert_called_with() fails.

    This patch changes the assert method, so it will check if update_port
    has been called on the main router port instead of checking the latest
    update_port call is on the main router port.

    Change-Id: I0ec1c90ee18bd9d0b027ad462cd6a3c6a079347f
    Closes-Bug: #1612896

[OpenStack Infra (hudson-openstack)]

This issue was fixed in the openstack/neutron 9.0.0.0b3 development milestone.