Jump to: navigation, search

Neutron/nvp-distributed-router

< Neutron
Revision as of 13:36, 28 June 2013 by Salvatore-orlando (talk | contribs) (Created page with "= Scope = 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 thi...")
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)

Scope

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

Use Cases

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

Implementation Overview

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

Configuration variables

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)

API

No change expected

Plugin Interface

No change expected

CLI Requirements

A CLI option for specifying the router type by name instead of id should be considered

Horizon Requirements

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.

Test Cases

We will adapt the FakeApiClient to support distributed routers emulation, or use mock to emulate NVP API responses for operations on distributed routers.