Bug 1803989 - Overcloud deploy with OSP16.0 using stateless IPv6 ctlplane in a DCN configuration fails
Summary: Overcloud deploy with OSP16.0 using stateless IPv6 ctlplane in a DCN configur...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-neutron
Version: 16.0 (Train)
Hardware: Unspecified
OS: Unspecified
high
high
Target Milestone: beta
: 16.1 (Train on RHEL 8.2)
Assignee: Bernard Cafarelli
QA Contact: Alex Katz
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-17 23:02 UTC by Mark Jones
Modified: 2020-07-29 07:50 UTC (History)
10 users (show)

Fixed In Version: openstack-neutron-15.0.3-0.20200327183443.9072631.el8ost
Doc Type: Bug Fix
Doc Text:
Before this update, it was not possible to deploy the overcloud in a Distributed Compute Node (DCN) or spine-leaf configuration with stateless IPv6 on the control plane. Deployments in this scenario failed during ironic node server provisioning. With this update, you can now deploy successfully with stateless IPv6 on the control plane.
Clone Of:
Environment:
Last Closed: 2020-07-29 07:50:34 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Launchpad 1864225 0 None None None 2020-02-22 13:16:36 UTC
OpenStack gerrit 709444 0 None MERGED Filter subnets on fixed_ips segment 2020-10-15 07:51:39 UTC
OpenStack gerrit 710546 0 None MERGED subnet create - segment aware auto-addr allocation 2020-10-15 07:51:40 UTC
OpenStack gerrit 710547 0 None MERGED Deny delete last slaac subnet with allocation on segment 2020-10-15 07:51:41 UTC
Red Hat Product Errata RHBA-2020:3148 0 None None None 2020-07-29 07:50:47 UTC

Comment 1 Bob Fournier 2020-02-18 18:48:25 UTC
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."

Comment 2 Harald Jensås 2020-02-24 10:39:22 UTC
@Mark, I've added a patch that I believe would fix the issue. Do you have bandwidth to test the patch?

Comment 14 Alex McLeod 2020-06-16 12:32:20 UTC
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 '-'.

Comment 16 errata-xmlrpc 2020-07-29 07:50:34 UTC
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


Note You need to log in before you can comment on or make changes to this bug.