Cannot determine network, or pool, a floating ip belongs to without multiple commands

Bug #1566090 reported by Carlos L. Torres on 2016-04-05
This bug affects 2 people
Affects Status Importance Assigned to Milestone
Fix Released

Bug Description

Previously using python-openstackclient I could retrieve with a single command to which network, or pool, a floating IP belonged to.

For example, here is an example output from version 1.0.4:
Note: I abbreviated the ids to fit this textarea

  # openstack --version && openstack ip floating list
  openstack 1.0.4
  | ID | Pool | IP | Fixed IP | Instance ID |
  | 07.. | public | | | 331e86ab-6caf... |
  | 0b.. | public | | | 77460666-2cd9... |
  | 99.. | public | | None | None |

On recent versions, the 'Pool' column now is missing, as well as the instance ID but that's for another day. Here's the output from version 2.3.0:

  # openstack --version && openstack ip floating list
  openstack 2.3.0
  | ID | Floating IP Address | Fixed IP Address | Port |
  | 07.. | | | 58... |
  | 0b.. | | | f4... |
  | 99.. | | None | None |

The problem is that now it takes multiple commands to determine to what network, or pool, a floating ip belongs to.

Previously, all it took was one command:

1) openstack ip floating list

But today, to determine if an available floating IP address belongs to network I would need to do the following:

1) List all networks and grab the ID of the network I'm interested:
   openstack network list

2) List all floating IPs to determine which are not allocated:
   openstack ip floating list

3) For each floating ip, get its details to determine its network:
   for ip in floating_ip:
       openstack ip floating show ip

4) If the 'floating_network_id' property matches the network from Step 1 then it belongs to that network.

It seems this change introduced the change to use Neutron floating ips extension:

Perhaps it could be extended to also fetch this other information.

description: updated
Reedip (reedip-banerjee) on 2016-04-05
Changed in python-openstackclient:
assignee: nobody → Reedip (reedip-banerjee)
Richard Theis (rtheis) wrote :

Hi Tang, can you please take a quick look at this bug?

Reedip (reedip-banerjee) wrote :

The current output is as follows:
reedip@reedip-VirtualBox:/opt/stack/python-openstackclient$ nova floating-ip-list
| Id | IP | Server Id | Fixed IP | Pool |
| 1ffad0b6-d968-4b10-8985-c56822954db5 | | - | - | public |
reedip@reedip-VirtualBox:/opt/stack/python-openstackclient$ neutron floatingip-list
| id | fixed_ip_address | floating_ip_address | port_id |
| 1ffad0b6-d968-4b10-8985-c56822954db5 | | | |

As discussed with Tang, if the computeV2 is enabled, pool will also be displayed
This would not be the case if networkv2 is enabled.

Reedip (reedip-banerjee) wrote :

I got the problem, I think
Earlier ( I mean in the V1.4.0 version), we had floating-ip command only for COMPUTE ( Nova)
After V2.2.0, both Neutron and Compute/Nova code were merged together
Now, you may be having Neutron enabled.

This allows the neutron code to work[1][2]:

I am proposing the following to override [1] for Listing output.
By default we will have Neutron output.
But if user passes --compute, then the compute related output would be displayed.
The only reason for adding such an option would be
- To maintain Neutron and Nova co-existence
- To allow default output of Neutron
- and to allow compute related output as well to be displayed.

@Richard: Lets discuss this in today's meeting

Thanks for looking at this.

What about 'extending' Neutron's response with more data from other API calls (e.g. Other Neutron API calls, or even Nova)? Unless there's a requirement that there has to be a 1:1 mapping from the commands to the API.

To be specific,

As you showed, if Neutron is available then we are making a request to

Can we, say, take that response and 'join' it with Nova's response as well[1]? That way you get the Pool Names as well, you could even make the requests in parallel.


Another alternative is to request the details of each floating ip (I'm not sure if it can be batched in a single request) and then add the floating_network_id to each floating_ip output row.

Dean Troyer (dtroyer) wrote :

We can't call Nova Net if Neutron is enabled as they both need to stand alone, and Nova Net goes away someday. We should get the info required to re-populate the Pool column.

Richard Theis (rtheis) wrote :

I think that the command should already have the info (i.e. floating_network_id) needed for the Pool column and thus no need to make further API calls.

Brian Hall (n-brian-b) wrote :

The underlying API the 'openstack ip floating list' command is invoking is 'GET /v2.0/floatingips', which returns the floating_network_id and the tenant_id, among other things. It would actually be helpful if the openstack command also returned both the floating_network_id and the tenant_id.

In particular, the tenant_id is useful in the case where the OS_USERNAME is an admin user, in which case you need to check if the floating IP is usable by the specified OS_TENANT_NAME. If the openstack command returned the tenant_id, it would save an extra API request to make that check.

Anne Gentle (annegentle) wrote :

My request would be to return the tenant_id, easy to grep for in the output.

Richard Theis (rtheis) on 2016-10-03
tags: added: network
Reedip (reedip-banerjee) wrote :

Ok, So I guess we can add the Project Information and Network information for the Floating IP , and it should provide the necessary information to the customer, as per the above discussion

Fix proposed to branch: master

Changed in python-openstackclient:
status: New → In Progress

Submitter: Jenkins
Branch: master

commit 8f8a8448a4adc1d250c253738688ff46e6456616
Author: Reedip <email address hidden>
Date: Tue Oct 4 16:25:07 2016 +0530

    Add necessary info to Floating IP list

    This patch adds the Network ID and Project ID
    for the listed floating IPs when Neutron is enabled
    for OpenstackClient.

    Change-Id: I823090f2e6d30acd72247d30956f48f4d7672a50

Changed in python-openstackclient:
status: In Progress → Fix Released

This issue was fixed in the openstack/python-openstackclient 3.4.0 release.

To post a comment you must log in.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers