Jump to: navigation, search

Difference between revisions of "Spec-QuantumMidoNetPlugin"

Line 19: Line 19:
 
MidoNetPluginV2 class extends db_base_plugin_v2.QuantumDbPluginV2 and l3_db.L3_NAT_db_mixin, and implements all the necessary methods to provide the Quantum L2 and L3 features.   
 
MidoNetPluginV2 class extends db_base_plugin_v2.QuantumDbPluginV2 and l3_db.L3_NAT_db_mixin, and implements all the necessary methods to provide the Quantum L2 and L3 features.   
  
In the virtual topology that gets constructed in the integration with Quantum, there is one virtual router that must always exist, called provider virtual router.  It is the virtual router belonging to the service provider, and it is capable of routing traffic among the tenant routers as well as routing traffic into and out of the provider network.  The virtual ports on this router are mapped to the interfaces on the 'edge' servers that are connected to the uplink routers.  Through the MidoNet API, you can configure BGP on this router to enable multi-homed BGP setup for fault tolerance, provided that the uplink routers can also speak BGP.
+
In the virtual topology that gets constructed in the integration with Quantum, there is one virtual router that must always exist, called provider virtual router.  It is the virtual router belonging to the service provider, and it is capable of routing traffic among the tenant routers as well as routing traffic into and out of the provider network.  The virtual ports on this router are mapped to the interfaces on the 'edge' servers that are connected to the service provider's uplink routers.  It is expected that this virtual router has already been set up and configured for the MidoNet plugin to function properly.
  
 
When a tenant creates a router in Quantum, a tenant virtual router is created in MidoNet, and linked to the provider router.  Just like l3_agent in Quantum, tenant virtual router acts as the gateway for the tenant networks, and it can also do NAT to implement the floating IP feature.  Thus with MidoNet plugin, there is no need to run l3_agent.
 
When a tenant creates a router in Quantum, a tenant virtual router is created in MidoNet, and linked to the provider router.  Just like l3_agent in Quantum, tenant virtual router acts as the gateway for the tenant networks, and it can also do NAT to implement the floating IP feature.  Thus with MidoNet plugin, there is no need to run l3_agent.
  
When a tenant creates a network in Quantum, a tenant virtual bridge is created in MidoNet, and linked to the tenant router.  Just like a Quantum network, a virtual bridge has ports.  When a VM is attached to Quantum network's port, it is also attached to [[MidoNet]]'s virtual bridge port.  
+
When a tenant creates a network in Quantum, a tenant virtual bridge is created in MidoNet, and linked to the tenant router.  Just like a Quantum network, a virtual bridge has ports.  When a VM is attached to Quantum network's port, it is also attached to MidoNet's virtual bridge port.  
  
 
MidoNet comes with its own DHCP implementation, so the Quantum's DHCP agent does not need to run.  The subnets in Quantum are registered to MidoNet DHCP service when created.
 
MidoNet comes with its own DHCP implementation, so the Quantum's DHCP agent does not need to run.  The subnets in Quantum are registered to MidoNet DHCP service when created.
  
[[MidoNet]]'s Libvirt VIF driver is not one of Nova's available VIF drivers.  You would have to get it from GitHub: https://github.com/midokura/midonet-openstack   
+
MidoNet's Libvirt VIF driver is not one of Nova's available VIF drivers because it requires the VM's interface type to be 'generic ethernet' in Libvirt, but as of G-3, this interface type is not supported.  You would have to get the VIF driver from GitHub: https://github.com/midokura/midonet-openstack   
  
Security groups: TODO
+
MidoNet plugin extends [[SecurityGroupDbMixin]], and implements all the features using [[MidoNet]]'s packet filtering API.  Quantum's security group agent does not need to run.
  
 
The plugin will support metadata server, but not with overlapping IP address support for G-3.  In the MidoNet design, nova-api is plugged into the MidoNet virtual networking in such a way that only traffic destined to and originated from the metadata server goes into the MidoNet's VM network.   
 
The plugin will support metadata server, but not with overlapping IP address support for G-3.  In the MidoNet design, nova-api is plugged into the MidoNet virtual networking in such a way that only traffic destined to and originated from the metadata server goes into the MidoNet's VM network.   
Line 54: Line 54:
 
[midonet]
 
[midonet]
 
midonet_uri = <MidoNet API server URI>
 
midonet_uri = <MidoNet API server URI>
 +
username = <MidoNet admin username>
 +
password = <MidoNet admin password>
 
provider_router_id = <Virtual provider router ID>
 
provider_router_id = <Virtual provider router ID>
 
metadata_router_id = <Virtual metadata router ID>
 
metadata_router_id = <Virtual metadata router ID>
username = <MidoNet admin username>
 
password = <MidoNet admin password>
 
  
 
</nowiki></pre>
 
</nowiki></pre>

Revision as of 02:32, 6 February 2013

Quantum MidoNet Plugin

'Scope:'

The goal of this blueprint is to implement Quantum plugin for MidoNet virtual networking platform.

Use Cases':'

To provide and enable MidoNet virtual networking technology as one of the options for those using Quantum as cloud networking orchestration.

Some of the benefits that come from using MidoNet in your IaaS cloud are:

  • the ability to scale IaaS networking into the thousands of compute hosts
  • the ability to offer L2 isolation which is not bounded by the VLAN limitation (4096 unique VLANs)
  • making your entire IaaS networking layer completely distributed and fault-tolerant

Implementation Overview:

MidoNetPluginV2 class extends db_base_plugin_v2.QuantumDbPluginV2 and l3_db.L3_NAT_db_mixin, and implements all the necessary methods to provide the Quantum L2 and L3 features.

In the virtual topology that gets constructed in the integration with Quantum, there is one virtual router that must always exist, called provider virtual router. It is the virtual router belonging to the service provider, and it is capable of routing traffic among the tenant routers as well as routing traffic into and out of the provider network. The virtual ports on this router are mapped to the interfaces on the 'edge' servers that are connected to the service provider's uplink routers. It is expected that this virtual router has already been set up and configured for the MidoNet plugin to function properly.

When a tenant creates a router in Quantum, a tenant virtual router is created in MidoNet, and linked to the provider router. Just like l3_agent in Quantum, tenant virtual router acts as the gateway for the tenant networks, and it can also do NAT to implement the floating IP feature. Thus with MidoNet plugin, there is no need to run l3_agent.

When a tenant creates a network in Quantum, a tenant virtual bridge is created in MidoNet, and linked to the tenant router. Just like a Quantum network, a virtual bridge has ports. When a VM is attached to Quantum network's port, it is also attached to MidoNet's virtual bridge port.

MidoNet comes with its own DHCP implementation, so the Quantum's DHCP agent does not need to run. The subnets in Quantum are registered to MidoNet DHCP service when created.

MidoNet's Libvirt VIF driver is not one of Nova's available VIF drivers because it requires the VM's interface type to be 'generic ethernet' in Libvirt, but as of G-3, this interface type is not supported. You would have to get the VIF driver from GitHub: https://github.com/midokura/midonet-openstack

MidoNet plugin extends SecurityGroupDbMixin, and implements all the features using MidoNet's packet filtering API. Quantum's security group agent does not need to run.

The plugin will support metadata server, but not with overlapping IP address support for G-3. In the MidoNet design, nova-api is plugged into the MidoNet virtual networking in such a way that only traffic destined to and originated from the metadata server goes into the MidoNet's VM network.

Data Model Changes:

N/A

Configuration variables:

1. To specify MidoNet plugin in Quantum (quantum.conf):


core_plugin = quantum.plugins.midonet.plugin.MidonetPluginV2


2. MidoNet plugin specific configuration parameters (midonet_plugin.ini):



[midonet]
midonet_uri = <MidoNet API server URI>
username = <MidoNet admin username>
password = <MidoNet admin password>
provider_router_id = <Virtual provider router ID>
metadata_router_id = <Virtual metadata router ID>


API's:

N/A

Plugin Interface:

N/A

Required Plugin support:

N/A

Dependencies:

N/A

CLI Requirements:

N/A

Horizon Requirements:

N/A

Usage Example:

N/A

Test Cases:

TODO