tempest ignors network.public_network_id values and discovers other shared network

[Martin Kopec]

I have two networks:

(overcloud) [stack@undercloud-0 ~]$ openstack network show private
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | |
| availability_zones | |
| created_at | 2018-09-05T11:30:33Z |
| description | |
| dns_domain | None |
| id | 7a791ac9-5b3b-4129-afb4-b9278fb9bc86 |
| ipv4_address_scope | None |
| ipv6_address_scope | None |
| is_default | None |
| is_vlan_transparent | None |
| mtu | 1450 |
| name | private |
| port_security_enabled | True |
| project_id | f24c27056de14ec2ac247a773a78e387 |
| provider:network_type | vxlan |
| provider:physical_network | None |
| provider:segmentation_id | 80 |
| qos_policy_id | None |
| revision_number | 4 |
| router:external | Internal |
| segments | None |
| shared | True |
| status | ACTIVE |
| subnets | |
| tags | |
| updated_at | 2018-09-05T11:31:45Z |
+---------------------------+--------------------------------------+
(overcloud) [stack@undercloud-0 ~]$ openstack network show public
+---------------------------+--------------------------------------+
| Field | Value |
+---------------------------+--------------------------------------+
| admin_state_up | UP |
| availability_zone_hints | |
| availability_zones | nova |
| created_at | 2018-08-16T09:44:06Z |
| description | |
| dns_domain | None |
| id | e2de7ebb-5b5f-406b-8a87-398cbb16550b |
| ipv4_address_scope | None |
| ipv6_address_scope | None |
| is_default | False |
| is_vlan_transparent | None |
| mtu | 1500 |
| name | public |
| port_security_enabled | True |
| project_id | f24c27056de14ec2ac247a773a78e387 |
| provider:network_type | flat |
| provider:physical_network | datacentre |
| provider:segmentation_id | None |
| qos_policy_id | None |
| revision_number | 9 |
| router:external | External |
| segments | None |
| shared | False |
| status | ACTIVE |
| subnets | 972ba648-8925-444b-9e51-026693416659 |
| tags | |
| updated_at | 2018-09-05T11:10:19Z |
+---------------------------+--------------------------------------+

and this test is failing due to the shared private network:
tempest.api.compute.servers.test_attach_interfaces.AttachInterfacesTestJSON.test_create_list_show_delete_interfaces_by_fixed_ip
with following error:
"Multiple possible networks found, use a Network ID to be more specific."

my network section in tempest.conf has the following variables set:
[network]
region = regionOne
public_network_id = e2de7ebb-5b5f-406b-8a87-398cbb16550b
floating_network_name = public
fixed_network_name = public

According to the error message, I should use a network ID, which I did, so therefore it seems like a tempest bug.
The problem seems to be with the shared network, if I set that network as --no-share, the test works as expected.

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/615425

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/615425
Committed: https://git.openstack.org/cgit/openstack/tempest/commit/?id=3588bb3f5ef546a0ef4d4ad621fd1be381b5fdaf
Submitter: Zuul
Branch: master

commit 3588bb3f5ef546a0ef4d4ad621fd1be381b5fdaf
Author: Attila Fazekas <email address hidden>
Date: Sun Nov 4 12:40:27 2018 +0100

    interfaces_by_fixed_ip no extra port

    test_create_list_show_delete_interfaces_by_fixed_ip was allowed
    to make one extra port/interface creation optional
    in case the CONF.compute.fixed_network_name was defined,
    but in this case the test failed at teardown time (double port delete).
    Turned out the test case normally not even deletes the fixed_ip port,
    inside the test case.

    There is no point for having 3 interface in this test, so just
    adding/deleting the fixed_ip interface
    and removing th 3th `extra` interface part from the test.

    The extra port was problematic in (multiple) shared network case,
    however fixed_ip interface creation part
    has the right logic to use an explicit network.

    Related-Bug: #1790864
    Change-Id: I6e3e53c4ac26b4fef09fefb9c590dfa91f577565

[Martin Kopec (mkopec)]

The review introduced by Attila has fixed my issue.