neutron

Questions on v2 Port

Asked by Sumit Naiksatam

Hi,

We have this open question in the v2 API Intro -
"Is there no way of detaching a interface from a port or moving it between networks now? (Or could this still be achieved on the nova side of things?)"

I believe the thinking here is to do this on the Nova side in the plug and unplug hooks of the VIF driver. That would mean that the actual plug and unplug trigger is outside of Quantum (more specifically, outside the plugin). Is this consistent with everyone else's thinking?

 As a follow up to the above, is there a pre-requisite to deleting a port? In the v1.x implementation we were checking if the "interface_id" attribute of the port was populated. In v2 do we check the "device_id" attribute? And if so, I believe the "device_id" can only be changed (or removed) via an "update_port" (since we don' have an uplug operation any more)?

Would appreciate your thoughts.

Thanks,
~Sumit.

Question information

Language:
English Edit question
Status:
Solved
For:
neutron Edit question
Assignee:
No assignee Edit question
Solved by:
Sumit Naiksatam
Solved:
Last query:
Last reply:
Revision history for this message
dan wendlandt (danwent) said : 		#1

You are correct that this would be handled on the Nova (or whatever plugs into quantum) side of things.

There are a couple options here.

The cleanest in my opinion would be for nova to support adding and removing NICs from a VM, in which case you could simply remove one NIC from a VM, while adding it to another. Thus, if the model is that the VM should change its IP, this interacts well with the mechanisms within the VM that will do things like issue a DHCP request. This is covered here: https://blueprints.launchpad.net/quantum/+spec/nova-quantum-interface-creation

Keeping the exact same device on the VM is also possible, though it clashes with the fact that IP allocations (if being used) are bound to a particular network (i.e., subnets are not one to many). Still, you could play games to avoid conflicting IPs, likely using the allocation_pool concept to make sure that multiple networks never allocated overlapping IPs. So assuming no IP conflicts, we could have nova expose the ability to swap the port-id for a particular NIC device, which as you suggest would trigger a change within the Vif plugging logic. It would also probably clear the device_id on the old port, and set it on the new one.

I believe the current behavior of the API is that deleting a network will fail if it has any ports defined on it. The idea is that if you no longer plan on using a port, you should delete it. The device_id is purely informational at this point, and its technically allowed for a service like Nova to not to set it .

I personally am not a huge fan of the check to prevent network deletion if ports exist (in v1 or v2)... I feel that a GUI or CLI can always add a check if it wants to, but that programmatic interfaces should be designed for people who know what they are doing. But that's another discussion :)

Revision history for this message
Sumit Naiksatam (snaiksat) said : 		#2

Thanks Dan for your thoughts on plug/unplug semantics. I wanted to confirm that Quantum is not handling this anymore (although we seem to be doing some part of this operation in the Quantum agents).

My question regarding delete was pertaining to deleting a port, not the network. I feel there should be safe-guards against accidental operations (like deleting a port which has a VIF associated). However, I am not sure how we can implement those checks (since device_id itself is optional). Maybe check on the status on the field before allowing the delete?