As I'm working on supporting security groups in the XenAPI backend in nova, I reckon I can contribute on the blueprints for security groups.
Blueprint: https://blueprints.launchpad.net/quantum/+spec/network-parity-sg > > - 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. Actually, I'm not entirely sure on this regard; can you elaborate a bit more on this point? The security groups are currently implemented by the compute driver. They are enforced by a firewall driver when the instance is started, rebooted, or migrated. Available firewall drivers include IpTables and nwfilter. >From my point view the iptables rules created by the firewall drivers should >still work even when networking is managed by Quantum; this unless both Open >vSwitch and the palo adapter are incompatible with nwfilter (which btw is >currently required by the iptables driver as well for enforcing basic >isolation rules) > 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. This makes sense, and it will be great is the security groups are exposed through the Openstac > -----Original Message----- > From: netstack- > bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net > [mailto:netstack- > bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] On Behalf Of > Brad Hall > Sent: 20 October 2011 23:20 > To: netstack@lists.launchpad.net > Subject: [Netstack] Nova network parity > > 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 -- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
