Nova remove-fixed-ip doesn't return an error message when incorrect fixed IP is removed

[Anna Babich]

Reproduce steps:
1. Create net01: net01__subnet, 192.168.1.0/24:
neutron net-create net01
neutron subnet-create net01 192.168.1.0/24 --enable-dhcp --name net01__subnet
2. Boot instance vm1 in net01:
NET_ID=$(neutron net-list | grep 'net01' | awk '{print $2}')
nova boot --flavor m1.micro --image TestVM --nic net-id=$NET_ID --security-groups default vm1
3. Note the fixed IP of vm1:
nova show vm1 | grep network
| net01 network | 192.168.1.36 |
4. Try to remove incorrect fixed IP from vm1:
nova remove-fixed-ip vm1 192.168.1.37

Expected result:
A message appears informing that the operation was not correct

Actual result:
Nothing happens and displayed

Nova version - http://paste.openstack.org/show/483603/

[Augustina Ragwitz (auggy)]

I confirmed that the remove_fixed_ip_from_instance method in nova/network/neutronv2/api.py throws a fairly generic exception when an error is encountered. Improving the exception information could improve user experience. Additionally I audited the unit test coverage for this method and found exception states are not directly tested (eg, what happens when an invalid IP is provided as the argument to this particular method). I would suggest the fix for this bug is 2 parts, 1) improve exception information for remove_fixed_ip_from_instance and 2) improve unit test coverage for error states.

[Augustina Ragwitz (auggy)]

I'm sorry, I completely misread the bug and realized that the issue is the exception information is being lost on its way back to the client. I am still working to confirm this.

[Augustina Ragwitz (auggy)]

I ran the test_remove_fixed_ip_from_instance unit test in test_neutronv2.py [1], and when I stepped through the code, I saw an exception was being hit, "'Unexpected method call Client.update_port(\\'my_portid1\\', {\\'port\\': {\\'fixed_ips\\': []}}) -> None'", and then the code [2] indicates it's logged if debug logging is enabled. I'm not sure if this is by design but in this case it means the unit test is passing even if the fixed ip removal fails. I am going to confirm this and ask that someone else who has more context take a look at it to make sure this is the intention. If dropping the exception is the intention, then at minimum a comment needs to be added to that section indicating why and also documentation updated if appropriate.

[1] https://github.com/openstack/nova/blob/master/nova/tests/unit/network/test_neutronv2.py#L2314
[2] https://github.com/openstack/nova/blob/master/nova/network/neutronv2/api.py#L943

[Augustina Ragwitz (auggy)]

Also, the unit test needs to be updated so it is actually testing the test_remove_fixed_ip_from_instance. If the decision is to drop the exception, then another step should happen in that test to check that the ip was actually removed.

[Sarafraj Singh (sarafraj-singh)]

Zhihai,
It's been a while since this bug was assigned to you and no patch yet. Removing you as assigned. Please assign yourself again if you are working on a fix.

[Pushkar Umaranikar (pushkar-umaranikar)]

I think there is an rpc cast call from nova api to network api https://github.com/openstack/nova/blob/master/nova/compute/rpcapi.py#L789.

rpc cast sends a message, doesn't wait for a reply. This is a async operation. For async API operations, you don't return an error code from the API if the operation fails. Hence, the API returns 202 response even if we pass a wrong IP as a argument. Also, 202 response suggests the request is accepted, it does not indicate that the response is OK.

Hence, marking this bug as invalid. Please feel free to reopen If I am missing something.

[Anna Babich (ababich)]

But if we have no Error message for end user when trying to delete incorrect fixed IP, it looks confusing and inaccurate. What about adding a microversion with support of IP validation before RPC request sending?

[Pushkar Umaranikar (pushkar-umaranikar)]

I am not sure about adding a microversion. I observed similar behavior when user tries an attach an invalid IP. Its not only restricted to a remove-fixed IP API.
Calling network api directly from compute API (without rpc cast call to compute manager) can resolve a problem. But I think rpc cast call is needed to redirect request to either nova network or neutron. Please correct me if I am wrong.
kindly, connect with nova cores on IRC for their suggestion. Marking bug as incomplete till that time.

[Pushkar Umaranikar (pushkar-umaranikar)]

We cannot solve the issue you reported without more information. Could you please provide the requested information ?

[Augustina Ragwitz (auggy)]

I've marked this as confirmed because there should be some communication to the end user that this operation failed or at least that there was a problem. If a mechanism already exists for this (eg, turning on debug logs) then we should clarify expectation that in our documentation.