The NVP platform provides an options for creating distributed routers, which allow one-hop forwarding for east-west traffic in virtualized networks. The aim of this blueprint is to enable quantum to leverage this feature
The use case for this blueprint is pretty straightforward: enable Quantum users to leverage the distributed router capability. However, this can happen in several ways according to the particular deployment, it might be possible to - use exclusively distributed routers - allow users to choose whether use a distributed or a standard router (or any other kind of router the nvp plugin might offer in the future) - restrict usage of the distributed routers to a particular set of tenants (or to admins only) - use only standard routers
Leveraging the RouterServiceType extension, we won't need to add a new extension to the Router resource. The router type will qualify it either as 'standard' or 'distributed' The same abstraction can also be used for further developments without API changes.
The NVP plugin will use this attribute to dispatch the Quantum API call to the appropriate code path which will either implement a standard or a distributed router. router type updates won't be allowed (allow_put is already False)
Data Model Changes
The RouterServiceType extension already provides the data model changes needed by this blueprint
According to the refactoring currently in progress for the service type definition, configuration variables will be added to quantum.conf or nvp.ini for each router type supported (ie: distributed and standard only at the moment)
No change expected
No change expected
A CLI option for specifying the router type by name instead of id should be considered
It would be nice to have this feature in Horizon, but since the routerServiceType extension is plugin-specific, the Horizon work is out of scope at the moment.
We will adapt the FakeApiClient to support distributed routers emulation, or use mock to emulate NVP API responses for operations on distributed routers.