The original plan for Folsom was that Quantum would manage security groups itself. However, this work did not get done, so for Folsom we are going to use Nova's iptables-based security groups.
We will likely end up breaking these issues into multiple reviews, so we may want to split these issues off into separate bugs, but I'm using this to track support for quantum + nova security groups as a whole.
There are a couple issues:
- In Folsom, quantum implements its own version of the nova-network API. This means that it must also make the security group RPC calls to compute when a VM fixed IP is allocated/deallocated. Note: in this case, this essentially amounts to when a VM is created or destroyed, since the nova + quantum v2 integration does not implement any mechanism for allocating new fixed IPs after boot.
- We need to populate the DHCP-server attribute of a network object, otherwise, running with security groups enabled will drop DHCP traffic from the VM. We've made the change in Quantum to set the device owner of the dhcp port to 'network:dhcp', so it should be pretty easy to query for the DHCP IP of a given network (note: this requires that the DHCP port is always created before any VMs are created on a network. I believe that is the case already, but we should confirm). Note: the nova data model will limit us to one v4 subnet per-network.
- Multiple NICs per VM. Nova's security groups are per-instance, so there may be some issues with how they apply to a VM with multiple NICs. We'll need to investigate.
- Open vSwitch by default is not compatible with iptables filtering on VIF devices. We think there's a pretty straight-forward work around for this, where we have a new type of vif-plugging in nova that actually plugins each vif into its own instance of the linux bridge, which would then be "uplinked" to an OVS bridge that does the tunneling
Note: a recent change to quantum made sure that ports created by DHCP have a particular device_owner, which should let us query them given a subnet-id. However, there may be a race condition here, if we need the dhcp_server to be populated right after the port is created. If its the first port on a subnet, the dhcp agent may not have created the corresponding port yet. This could be an issue, as the DHCP server IP may be needed at VM boot time.