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): Queens/OSP13 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 172.16.0.0/16. 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.
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':'172.25.10.0/24','nexthop':'172.25.0.254'}, {'destination':'172.25.11.0/24','nexthop':'172.25.0.254'}] Or, in a different format: InternalApiInterfaceRoutes: - destination: 172.25.10.0/24 nexthop: 172.25.0.254 - destination: 172.25.11.0/24 nexthop: 172.25.0.254 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.
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/RHEA-2019:2811
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days