Per the discussion on IRC I'm sending out a mail to clarify the work
that needs to be done (short-term) for nova networking parity.

The general idea is that the functionality already exists in nova
(aside from pieces related to Melange integration) so we might as well
leverage it in the short term in order to allow people to put Quantum
into production deployments earlier rather than later.  The interfaces
will be sufficiently abstracted (or close enough) that we will be able
to (hopefully) plug Quantum L3 services in at a later point.

The DHCP work took a few days and I imagine the other work will be on
the order of days (for each item) as well.

This is from an email Dan sent this on tuesday (it's a good summary,
so I'd rather not retype it) in response to the nova subteams:

> 2) provide "nova network parity" in that any use case possible with nova
> networking should be possible with Quantum as well (there are currently
> large gaps).
>
> The basic model of integrating with Nova will be the same as in Diablo:
> running Nova with a standard Network Manager will continue to work, but
> running it with QuantumManager will leverage Quantum + Melange.  To start,
> Quantum will just leverage the existing Nova "gateway" implementation (DHCP,
> Floating IP, NAT, etc). , allowing them to be "plugged" into Quantum
> networks just like Nova vNICs.
>
> Major areas for nova parity include:
>
> - DHCP integration: pretty simple, but requires some small changes to
> generalize functionality in linux_net.py and changes to QuantumManager
>

  Blueprint: https://blueprints.launchpad.net/quantum/+spec/network-parity-dhcp
  Code: https://review.openstack.org/#change,916

>
> - Floating IPs: the quantum manager class needs to implement the floating IP
> python interface.  may need to tweak floating IP code in manager.py to
> generalize it a bit so quantum can leverage it with melange.  I think
> there's a good amount of work here, particularly if we plan on using melange
> to store floating IP info.

  Blueprint: 
https://blueprints.launchpad.net/quantum/+spec/network-parity-floating

> - L3 gateway + NAT: similar to what is required for DHCP.

  Blueprint: 
https://blueprints.launchpad.net/quantum/+spec/network-parity-floating
 (this is currently combined in the floating blueprint but I can break
it out)

> - Security groups:  security groups as implemented with iptables or libvirt
> won't work with either of the existing Quantum plugins.  We'll actually need
> a way of letting Quantum implement security groups as well.  This will
> likely amount to generalizing the ec2 api implementation to either be able
> to use a Nova implementation of security groups, or forward requests to a
> Quantum security groups API.

  Blueprint: https://blueprints.launchpad.net/quantum/+spec/network-parity-sg

> - cloudpipe VPN:  now that tenants can have multiple networks, with
> QuantumManager we'll need to add an optional flag to specify that a VPN VM
> should be spun up on a particular network.  I don't see a ton of work here.

  Blueprint: https://blueprints.launchpad.net/quantum/+spec/network-parity-vpn

Thanks,
Brad

-- 
Mailing list: https://launchpad.net/~netstack
Post to     : netstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~netstack
More help   : https://help.launchpad.net/ListHelp

Reply via email to