Bug 1803989

Including neutron team to take a look as it seems that there is an issue with multiple ports being created in this case.  From Mark's email describing this problem...

"In my configuration, I have two subnets/segments on the control plane network (subnets ctlplane-subnet and dcn1-subnet) representing two leafs and what I notice when Heat defines ports (or indeed if I manually define them) is that the ports are ending up with fixed_ips on both subnets when I would imagine that they should have just a single entry. For example, after the cloud deployment failure, the ports I have are:

+--------------------------------------+-------------------------+-------------------+--------------------------------------------------------------------------------------------+--------+
| ID                                   | Name                    | MAC Address       | Fixed IP Addresses                                                                         | Status |
+--------------------------------------+-------------------------+-------------------+--------------------------------------------------------------------------------------------+--------+
| 134d4b76-b363-4127-8580-e98771727eaa |                         | fa:16:3e:97:6d:3b | ip_address='fd00:6::f816:3eff:fe97:6d3b', subnet_id='fe461023-389d-4ce3-a139-42e0d272aa4e' | ACTIVE |
|                                      |                         |                   | ip_address='fd00:7::f816:3eff:fe97:6d3b', subnet_id='9c463bf7-0d6b-498e-a8b5-2c6c8bef7b56' |        |
| 25b275db-6462-46cb-a857-9a1b376bc065 | ovn_dbs_virtual_ip      | fa:16:3e:1f:bb:09 | ip_address='fd00:10::e9', subnet_id='ab23dd83-3b21-481d-9af7-e16f0d43d4f5'                 | DOWN   |
| 357bc495-2ff3-4599-ac3f-5f5d6f9fcf20 | public_virtual_ip       | fa:16:3e:30:31:26 | ip_address='fd00:50::1d2', subnet_id='cc754339-517f-45fe-b54f-a3b11b71182e'                | DOWN   |
| 43167f19-9894-4a01-9fa5-ffb4b4fdb76f | Controller-port-0       | fa:16:3e:65:41:3f | ip_address='fd00:6::f816:3eff:fe65:413f', subnet_id='fe461023-389d-4ce3-a139-42e0d272aa4e' | DOWN   |
|                                      |                         |                   | ip_address='fd00:7::f816:3eff:fe65:413f', subnet_id='9c463bf7-0d6b-498e-a8b5-2c6c8bef7b56' |        |
| 48e4cfac-9715-4d81-8d00-bbddffc1c379 | control_virtual_ip      | fa:16:3e:55:a4:9f | ip_address='fd00:6::f816:3eff:fe55:a49f', subnet_id='fe461023-389d-4ce3-a139-42e0d272aa4e' | DOWN   |
|                                      |                         |                   | ip_address='fd00:7::f816:3eff:fe55:a49f', subnet_id='9c463bf7-0d6b-498e-a8b5-2c6c8bef7b56' |        |
| 55fa21ea-961a-4e5c-a4a6-9b92fd7f21c6 | Controller-port-0       | fa:16:3e:ea:68:53 | ip_address='fd00:6::f816:3eff:feea:6853', subnet_id='fe461023-389d-4ce3-a139-42e0d272aa4e' | DOWN   |
|                                      |                         |                   | ip_address='fd00:7::f816:3eff:feea:6853', subnet_id='9c463bf7-0d6b-498e-a8b5-2c6c8bef7b56' |        |
| 66e152db-44a9-4333-adac-c7ea8c7818a4 | storage_mgmt_virtual_ip | fa:16:3e:94:b1:dd | ip_address='fd00:30::214', subnet_id='96517258-93c1-4e0c-b4d1-550828969c8d'                | DOWN   |
| 8ec29ce4-fa5b-4660-bfa4-1a8b775b5206 | redis_virtual_ip        | fa:16:3e:ca:6d:88 | ip_address='fd00:10::1af', subnet_id='ab23dd83-3b21-481d-9af7-e16f0d43d4f5'                | DOWN   |
| 963a4446-934f-4593-bffa-3c2a1128a6eb | ComputeDCN1-port-0      | fa:16:3e:df:a7:90 | ip_address='fd00:6::f816:3eff:fedf:a790', subnet_id='fe461023-389d-4ce3-a139-42e0d272aa4e' | DOWN   |
|                                      |                         |                   | ip_address='fd00:7::f816:3eff:fedf:a790', subnet_id='9c463bf7-0d6b-498e-a8b5-2c6c8bef7b56' |        |
| 9900396e-5ea9-4f33-ba41-047cdc5f7a36 | internal_api_virtual_ip | fa:16:3e:03:cb:51 | ip_address='fd00:10::29a', subnet_id='ab23dd83-3b21-481d-9af7-e16f0d43d4f5'                | DOWN   |
| 9dbef3af-5da4-4781-94c3-b27a504dc07d | storage_virtual_ip      | fa:16:3e:1c:a9:94 | ip_address='fd00:20::212', subnet_id='b26d1a85-2e24-4b11-b2c7-1ad4f289edb3'                | DOWN   |
| d41ccf49-744b-41fc-b182-f3e64ff90735 | Controller-port-0       | fa:16:3e:35:fe:d8 | ip_address='fd00:6::f816:3eff:fe35:fed8', subnet_id='fe461023-389d-4ce3-a139-42e0d272aa4e' | DOWN   |
|                                      |                         |                   | ip_address='fd00:7::f816:3eff:fe35:fed8', subnet_id='9c463bf7-0d6b-498e-a8b5-2c6c8bef7b56' |        |
| fd988404-c8c1-486d-bc47-580106de4f20 | ComputeDCN1-port-0      | fa:16:3e:96:1c:b7 | ip_address='fd00:6::f816:3eff:fe96:1cb7', subnet_id='fe461023-389d-4ce3-a139-42e0d272aa4e' | DOWN   |
|                                      |                         |                   | ip_address='fd00:7::f816:3eff:fe96:1cb7', subnet_id='9c463bf7-0d6b-498e-a8b5-2c6c8bef7b56' |        |
+--------------------------------------+-------------------------+-------------------+--------------------------------------------------------------------------------------------+--------+

So here I have not only my VIPs with multiple fixed_ips but also the ports associated with the compute and controller nodes in Ironic (it is also retrying to deploy the node which I suspect is why we see two ComputeDCN1-port-0 and Controller port 0).

Even if I provide a --fixed-ip with the subnet I want to use during a CLI port create using the ctlplane network to try and force a specific subnet I still get a port with two fixed_ips return so it behaves as if its ignoring that parameter.

Looking through the code seems to suggest that the default behaviour when creating a port on a stateless DHCPv6 network with multiple subnets/segments defined is to return back fixed_ip entries for all subnets unless you specify host binding information in which case it selects only the subnet that the host can attach to. So that seems to explain why I am seeing multiple fixed_ips -- but given what we are trying to do with the deployment here that seems like a problem."

@Mark, I've added a patch that I believe would fix the issue. Do you have bandwidth to test the patch?

If this bug requires doc text for errata release, please set the 'Doc Type' and provide draft text according to the template in the 'Doc Text' field. The documentation team will review, edit, and approve the text.

If this bug does not require doc text, please set the 'requires_doc_text' flag to '-'.

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2020:3148