Bug 1477642 - [RFE][spine-leaf] Ironic support for Routed Networks
[RFE][spine-leaf] Ironic support for Routed Networks
Status: ON_QA
Product: Red Hat OpenStack
Classification: Red Hat
Component: python-networking-baremetal (Show other bugs)
13.0 (Queens)
Unspecified Unspecified
medium Severity medium
: Upstream M3
: 13.0 (Queens)
Assigned To: Harald Jensås
: FutureFeature, Triaged
Depends On: 1544785 1477307
Blocks: 1214284
  Show dependency treegraph
Reported: 2017-08-02 10:17 EDT by Bob Fournier
Modified: 2018-03-17 09:02 EDT (History)
10 users (show)

See Also:
Fixed In Version: python-networking-baremetal-1.0.0-0.20180220161644.deb466b.el7ost puppet-neutron-12.3.1-0.20180222064632.07b93f1.el7ost
Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of:
Last Closed:
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)

External Trackers
Tracker ID Priority Status Summary Last Updated
RDO 11243 None rpm-master: MERGED openstack/networking-baremetal-distgit: Initial packaging (Ia986756ed848c2ecd4aaf94444f9559bf79fff45) 2018-02-28 08:32 EST
Launchpad 1658964 None None None 2017-08-07 12:20 EDT
OpenStack gerrit 456235 None master: MERGED networking-baremetal: Add baremetal neutron agent (I34f288b07833cbe8f5593e521263034def911faf) 2018-02-28 08:32 EST
OpenStack gerrit 521838 None master: MERGED networking-baremetal: Switch from MechanismDriver to SimpleAgentMechanismDriverBase (I952c7afbef5e80e3fd2a7f32f11bdc522e... 2018-02-28 08:32 EST
OpenStack gerrit 531637 None master: MERGED ironic: Wait for ironic-neutron-agent to report state (I041761dd896c9d89dc6cf7bafc991a0697ded05b) 2018-02-28 08:32 EST
OpenStack gerrit 533707 None master: MERGED networking-baremetal: start_flag = True, only first time, or conf change (I6860483c957988843416b2d913deb97fbb18c391) 2018-02-28 08:31 EST
OpenStack gerrit 536040 None master: MERGED ironic: Flat networks use node.uuid when binding ports. (I7841d59c3590106dd8ac7e625a9db7b47674fe29) 2018-02-28 08:31 EST
OpenStack gerrit 537826 None master: MERGED puppet-neutron: Add networking-baremetal ml2 plug-in (Iddbda9741456d66c664bebfb675cd453c6e66b65) 2018-02-28 08:31 EST
OpenStack gerrit 539405 None master: MERGED puppet-neutron: Add networking-baremetal - ironic-neutron-agent (Ibaf539230b5b500d5b80d5b486a30f60e7a6dc4a) 2018-02-28 08:31 EST
OpenStack gerrit 542799 None master: MERGED puppet-neutron: Fix dependency cycle issue (Ie7bb7d00c606a928b58cdc45e04c4fce45208fe5) 2018-02-28 08:31 EST

  None (edit)
Description Bob Fournier 2017-08-02 10:17:25 EDT
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.
Comment 2 Bob Fournier 2017-08-07 12:20:46 EDT
See also upstream bug - https://bugs.launchpad.net/ironic/+bug/1658964
Comment 6 Bob Fournier 2017-12-07 13:02:55 EST
Harald - assigning this to you as you took over the upstream patch.
Comment 7 Bob Fournier 2018-01-17 13:51:21 EST
FFE text:

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?

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