Description of problem:
This RFE tracks support for Routed Networks in Ironic, specifically the functionality in networking-baremetal to populate neutron with information about each Ironic node's NIC to physnet mappings.
The upstream patch is here: https://review.openstack.org/#/c/456235/
This depends on the work that was done in Pike for physical network awareness as tracked with this RFE - https://bugzilla.redhat.com/show_bug.cgi?id=1477307.
See also upstream bug - https://bugs.launchpad.net/ironic/+bug/1658964
Harald - assigning this to you as you took over the upstream patch.
This doc is to request a Feature Freeze exception for OSP-13 for the following BZs which are related to the Spine/Leaf functionality for OSP-13.
In OSP-12, Spine/Leaf with composable networks was added in OSP-12, it did not include support for a routed provisioning network. This routed provisioning network support is what is planned on being added in OSP-13. The remaining patches are up for review and includes changes in THT, heat, instack-undercloud, networking-baremetal (formerly under ironic), and neutron.
It is anticipated that the remaining patches will land in M3.
Regarding the set of questions for these BZs:
What is the potential impact to other DFGs?
There will be very little impact to other DFGs, however there are some services which still require a shared VLAN in order to perform clustering. We will need to identify which services can be spread across multiple subnets, and then potentially look at refactoring those services in a future version.
What are the new software dependencies, if any, required by the feature?
All associated patches are listed in the BZs.
Will the DFG be able to test it in time for the release?
In Pike we had a joint collaboration between QE and development to test many features and we plan on doing this also for this feature. The entire composable networks setup was developed between development and QE.
Will it block testing of anything else?
Will documentation be able to do its work in time? (Have you checked with the doc team?)
This feature, as the related Spine/Leaf feature did in Pike, requires a lot of engineering assistance for documentation. As a DFG we anticipate in helping document this feature. We have already produced a Spine/Leaf document and we will be augmenting this document for these BZs.
What other work will not get done?
We have engineering resources dedicated to this feature so it will not affect any other features planned for OSP-13. Additionally, almost all of the coding is finished, and we are in the process of obtaining reviews and doing final cleanup.
What is the business impact of not doing this now?
We have had multiple customers requesting support for Spine/Leaf. In OSP-12, a partial solution was implemented that did not include the provisioning network. This feature completes the Spine/Leaf functionality and is desired by customers that do not want to implement the partial solution in OSP-12. In particular, NFV customers have been waiting for this feature to be available for a number of releases.
What is the best case/worst case scenario for this landing (timing/impact)?
Best case: All remaining patches associated with both BZs land in OSP-13 M3.
Good case: Enough patches land in OSP-13 M3 so that a “Spine/Leaf with routed provisioning network” solution can be implemented with some manual configuration steps documented.
Worst case:Remaining patches do not land and Spine/Leaf provisioning network support gets deferred to OSP-14.
What other Feature Freeze Exception are being requested?
Was able to introspect nodes residing on separated spine leafs.
Was able to deploy OC.
Was able to populate the OC with instance reachable via floating IP.
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.