Difference between revisions of "QuantumNetworkManager"
Clark Boylan (talk | contribs) |
|||
| Line 1: | Line 1: | ||
__NOTOC__ | __NOTOC__ | ||
| − | We are creating a new | + | We are creating a new NetworkManager class that supports functionality akin to the existing network managers but using Quantum. |
| − | Code changes to existing network managers should be minimal (For the most part, we can sub-class existing | + | Code changes to existing network managers should be minimal (For the most part, we can sub-class existing NetworkManagers to inherit their IPAM capabilities, and do Quantum on top). Our current design is based on the FlatManager, as with multi-nic this actually let's us support "private" networks as well. |
| − | It will be possible to run | + | It will be possible to run QuantumManager in one of several "modes" (names will be changed): |
* Pre-allocated mode: Networks are created ahead of time and have an explicit project_id associated with them if they are tenant-specific. Each VM for that tenant will get an interface on such a network. If no project_id is associated with a network, it is considered global and every VM will get an interface on that network. This capability should cover both the existing Flat & VLAN models | * Pre-allocated mode: Networks are created ahead of time and have an explicit project_id associated with them if they are tenant-specific. Each VM for that tenant will get an interface on such a network. If no project_id is associated with a network, it is considered global and every VM will get an interface on that network. This capability should cover both the existing Flat & VLAN models | ||
* Null mode: No network orchestration is performed. The assumption is that an external entity is plugging VM interfaces into Quantum networks, and Nova should do nothing. | * Null mode: No network orchestration is performed. The assumption is that an external entity is plugging VM interfaces into Quantum networks, and Nova should do nothing. | ||
Revision as of 22:12, 16 February 2013
We are creating a new NetworkManager class that supports functionality akin to the existing network managers but using Quantum.
Code changes to existing network managers should be minimal (For the most part, we can sub-class existing NetworkManagers to inherit their IPAM capabilities, and do Quantum on top). Our current design is based on the FlatManager, as with multi-nic this actually let's us support "private" networks as well.
It will be possible to run QuantumManager in one of several "modes" (names will be changed):
- Pre-allocated mode: Networks are created ahead of time and have an explicit project_id associated with them if they are tenant-specific. Each VM for that tenant will get an interface on such a network. If no project_id is associated with a network, it is considered global and every VM will get an interface on that network. This capability should cover both the existing Flat & VLAN models
- Null mode: No network orchestration is performed. The assumption is that an external entity is plugging VM interfaces into Quantum networks, and Nova should do nothing.
- API mode: Recent extensions to the Nova API propose a mechanism for specifying the network that an interface should be plugged into. We would like to leverage this mechanism and let the API user pass in a Quantum network id.
We will also be either extending nova-manage or creating a separate management utility to create these networks from the command line (remote API for automating not planned for this release).
This manager will also take on the task of communicating "interface bindings" to Quantum.
In the short-term, we are also thinking on having this manager communicate to Quantum to indicate which tenant "owns" a nova vif, and thus has the right to attach that VIF to a Quantum port. This is related to the Quantum API auth work.
