Improve Nova Quantum Integration

I believe a lot of this work is already done, but that we need to rewrite things using the v2.0 API spec. Hence I'm moving this issue to blocked until we at least have a spec good enough for you to use available.

Yong is going to help with this as well to try and get it there in time for F-2. It will be tight.

Gerrit topic: https://review.openstack.org/#q,topic:bp/improved-nova-quantum-integration,n,z

Addressed by: https://review.openstack.org/8920
    add instance_id into port model blueprint improved-nova-quantum-integration

Here are some notes I've written on up this change-set:

There are two high-level goals with the patch:
1) Allow Nova to communicate with the Quantum v2 API, so that VMs can use networks created via Quantum API calls (in Essex, Quantum networks has to be created via nova-manage, with nova-network proxying calls to Quantum, since nova-network stored network data and IPAM data in Nova DB. Trey's patchset stores no network data in the nova DB, which is good, but uses the Quantum v1 API + Melange IPAM, whereas we want to use the IPAM in the Quantum v2 API).
2) Remove nova-network from the picture when Quantum is in use. The idea is that rather than using the internal nova-network API to make an RPC call to the nova-network process, which then calls Quantum, we just have an alternate implementation of the internal nova-network API that calls Quantum directly from the nova-compute process. This was Vish's suggestion, and is how Trey's patch already works.

Some other things to note:
- This patch will completely remove Nova logic for DHCP and L3/NAT when Quantum is in use. These functions are moving to Quantum (DHCP is targeted for F-2, L3/NAT will be F-3).
- Trey's patch includes an implementation of network creation/deletion within Nova. I think we can simplify things by assuming network creation/deletion is done directly via the Quantum v2 API, using the quantum cli. All we need to implement would be the allocate_for_instance, deallocate_for_instance, and get_instance_nw_info calls (note: 'validate_networks' is also helpful, but could be done in a later patch).
- Our new version should be able to import and use the python-quantumclient code directly, rather than relying on the embedded quantum client.
- I would vote that we remove the old nova-network QuantumManagaer logic during Folsom, though probably not right away with this patchset. Perhaps we should add a comment at the top of those files that they are targeted for removal.
- We also need to make sure that VIFs are not stored anywhere in the Nova DB (since the vif table had a foreign key to the networks table). I think that's already the case with Trey's patch, but we should make sure.
- With Quantum v2, the notion of an interface-id that is separate from the port-id has gone away. For OVS vif-plugging, we should make sure that iface-id is set to the port-uuid (the associated plugin changes are already in progress). Looking at Trey's patch, I think we can just set the vif-id to be the port-id, but I'm not sure.
- Trey's patch replicates the behavior of the old QuantumManager in allocate_for_instance, in that if no networks are specfied when the VM boots, the VM gets a NIC for each tenant network, plus, a NIC for each network on the "deafult tenant" (e.g., the service provider's public networks). I think we need to revamp this logic, but its still up for discussion exactly how.
- The quantum v2 client uses keystone... not sure whether this requires a new set of flags to configure the inputs for this.
- Trey's branch passes some additional data to Quantum, including the allowed_address_pairs, nova availability zone, rxtx factor. These should be defined as proper extensions, so we can just omit them for now.

I see at least two threads of work here:
1) implementing the new versions of allocate_for_instance, deallocate_for_instance, and get_instance_nw_info that convert data from v2 API calls to the nova network models.
2) writing unit tests for these methods, mocking out the calls to the quantum v2 client.

nova.conf:
 network_api_class=nova.network.quantumv2.api.API
 quantum_admin_username=admin
 quantum_admin_password=password
 quantum_admin_tenant_name=admin
 quantum_admin_auth_url=http://localhost:5000/v2.0
 quantum_auth_strategy=keystone
 quantum_url=http://localhost:9696/
 libvirt_vif_driver=nova.virt.libvirt.vif.QuantumLinuxBridgeVIFDriver