Bug 1546844 - [RFE] Add per-network route support for routed spine-and-leaf [NEEDINFO]
Summary: [RFE] Add per-network route support for routed spine-and-leaf
Alias: None
Product: Red Hat OpenStack
Classification: Red Hat
Component: openstack-tripleo-heat-templates
Version: 14.0 (Rocky)
Hardware: Unspecified
OS: Unspecified
Target Milestone: Upstream M2
: 15.0 (Stein)
Assignee: Dan Sneddon
QA Contact: Alexander Chuzhoy
Depends On:
TreeView+ depends on / blocked
Reported: 2018-02-19 18:25 UTC by Dan Sneddon
Modified: 2019-09-26 10:44 UTC (History)
7 users (show)

Fixed In Version: openstack-tripleo-heat-templates-10.5.1-0.20190701110422.889d4d4.el8ost
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Last Closed: 2019-09-21 11:15:27 UTC
Target Upstream Version:
gregraka: needinfo? (dsneddon)
gregraka: needinfo? (dsneddon)

Attachments (Terms of Use)

System ID Private Priority Status Summary Last Updated
OpenStack gerrit 580235 0 'None' MERGED Add host routes to subnets 2020-04-02 23:06:46 UTC
OpenStack gerrit 580236 0 'None' MERGED Add per-network routes to NIC templates 2020-04-02 23:06:46 UTC
OpenStack gerrit 580596 0 'None' MERGED host_routes using get_attr (Composable Networks) 2020-04-02 23:06:46 UTC
Red Hat Product Errata RHEA-2019:2811 0 None None None 2019-09-21 11:15:50 UTC

Description Dan Sneddon 2018-02-19 18:25:07 UTC
Description of problem:
In Queens we developed routed spine-and-leaf as well as composable network interface configuration using Jinja2. Unfortunately, a user who is deploying with routed spine-and-leaf isolated networks still needs to develop custom NIC configs with manually-added routes. This should happen automatically in the sample NIC config templates, to illustrate how to implement supernets for isolated network routing. 

Version-Release number of selected component (if applicable):

Actual results:
The installer has to hand-craft the routes in the NIC config templates for each role.

Expected results:
The sample NIC configs should be capable of automatically inserting the routes if needed based on information in the network_data.yaml file.

Additional info:
The supernets ensure that traffic across a single network (Internal API for instance) will use the correct interface on both client and server. To achieve this, all roles should use Internal API subnets that are part of one supernet. For instance, the individual racks might use 172.16.X.0/24 subnets, which are all part of the supernet Each role should have a route on the local Internal API network that directs traffic to the supernet to route via the local Internal API gateway router. This ensures that both request and return traffic will use the Internal API interfaces.

We will need to add an optional supernet parameter for each network, and implement this parameter in the NIC config templates.

Comment 9 Dan Sneddon 2019-01-15 18:44:57 UTC
Note that while the original description of work in this RFE references supernets, we eventually decided to implement support for an arbitrary list of routes. This is more flexible than a single supernet. Routes are provided for each network in the following form:

InternalApiInterfaceRoutes: [{'destination':'','nexthop':''}, {'destination':'','nexthop':''}]

Or, in a different format:

  - destination:
  - destination:

You can still use a supernet as a destination, but this format provides fine-grained control over which routes are added to each network.

The end result of the above parameters is that the routes will be added to the network config outputs in THT/network/config/*, where the role.role.j2.yaml file will be used to generate config files for each custom role.

Comment 15 errata-xmlrpc 2019-09-21 11:15:27 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.


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