Comment 2 for bug 1430512

I somehow agree with both API calls for expecting not very different results at the end: I guess it is probably more flexible and precise to have the choice of what level of detailed API wrapper to choose from for different types of apps tenants:

1. ”neutron port-update <port_id> —fixed_ips type=dict list=true subnet_id=<subnet_id>,ip_address=<fixed_ip>"
—> Dealing with the precise details of what exact subnet_id (as well as port_id) you want to add the fixed_ip to;

2. “nova remove-fixed-ip <server_name> <fixed_ip>” and ”nova add-fixed-ip <server_name> <network_name>”
—> Not dealing with these details and still removing/adding fixed-ip to (a) the same interface as what neutron ports allow you to do or to (b) a different interface in different subnet in same neutron network as with what multiple-if-1-net BP provided.

Regarding choice (2): it seems that even if the requested network still have some fixed IPs available in one of its other subnets, if the first subnet ran out of fixed IPs, you cannot add a new fixed IP to the instance.
nova add-fixed-ip API call returns HTTP 202 Accepted with empty body and nova-compute logs displays a thing similar to this:
"Unable to update port f6cffe78-c183-4a72-8831-f19235117a6b on subnet 5c190dbd-7753-44e6-8aae-48811b5bce99 with failure: No more IP addresses available on network 95f6fb2d-10cc-4b77-8db6-652600e35d43."

So I guess it is not impossible to do (a) to rewrite add-fixed-ip to handle the case of IP exhaustion in "first" subnet. Also it seems that API call "add-fixed-ip" list_subnets() uses a different order of subnets in same requested network different from the API call "nova boot --nic net-id", ... i.e. order of "first" subnet is relative to what API call is used.

Besides, it is not impossible to do (b) to rewrite to remove/add fixed-ip from different interface in different subnets in same neutron network... Among other things, if the network backend implementation (using overlays for instance) doesn't broadcast one subnet to another one in same network, then it should be less inefficient to have multiple NICs on different subnets on same network for the same instance.