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

[Carlos L. Torres]

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 | 10.50.48.91 | 172.16.1.41 | 331e86ab-6caf... |
  | 0b.. | public | 10.50.48.102 | 172.16.1.50 | 77460666-2cd9... |
  | 99.. | public | 10.50.48.130 | 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.. | 10.50.48.91 | 172.16.1.41 | 58... |
  | 0b.. | 10.50.48.102 | 172.16.1.50 | f4... |
  | 99.. | 10.50.48.130 | 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:

https://review.openstack.org/#/c/280535/

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

[Richard Theis (rtheis)]

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

[Reedip (reedip-banerjee-deactivatedaccount)]

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 | 172.24.4.3 | - | - | 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 | | 172.24.4.3 | |
+--------------------------------------+------------------+---------------------+---------+
reedip@reedip-VirtualBox:/opt/stack/python-openstackclient$

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-deactivatedaccount)]

@Carlos:
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]:
[1]:https://github.com/openstack/python-openstackclient/blob/master/openstackclient/network/common.py#L81-L87
[2]:https://github.com/openstack/python-openstackclient/blob/master/openstackclient/network/v2/floating_ip.py#L134-L182

Proposal:
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

[Carlos L. Torres (carlos-torres)]

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
http://developer.openstack.org/api-ref-networking-v2-ext.html#listFloatingIps

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.

[1]: http://developer.openstack.org/api-ref-compute-v2.1.html#listfloatingipsObject

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)]

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)]

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)]

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)]

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

[Reedip (reedip-banerjee-deactivatedaccount)]

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

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: master
Review: https://review.openstack.org/381658

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/381658
Committed: https://git.openstack.org/cgit/openstack/python-openstackclient/commit/?id=8f8a8448a4adc1d250c253738688ff46e6456616
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
    Closes-Bug:#1566090

[OpenStack Infra (hudson-openstack)]

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