[RFE] Bulk Floating IP allocation

Hi Alex, thanks for reporting this new feature request. I wonder, is this an action you would like to do via the GUI only, or also via the Rest API?

Hi Andreas, I believe both option should be available

tnx

It is true that we have bulk support for certain operation like networks and ports. I am personally opposed to extending support to floating IPs (i.e. I take the same stance that Nova guys take against orchestration). Let's see if I am a minority.

Let's discuss it during next meeting to see if can get an agreement on this one.

Marking Confirmed for now, but any change in Horizon is blocked on the API supporting it.

We could provide a client api that accepts multiple floating ips and iteratively tries and clean up the log. Would that satisfy the Horizon requirement? I am against adding API support for this.

The only reason I could see supporting a change in the API for this is if we could try allocating a contiguous range of IP addresses in one shot (and fail if that can't be achieved. While I don't fully understand the need for this, we've have customers asking to be able to allocate contiguous blocks of floating IPs.

If it is just to avoid having to send multiple API requests then I agree with Armando about being against it.

Why doesn't Horizon just call the API multiple times? Why even put in a client change?

Carl - if I'm remembering correctly our customers wanted a contiguous space to make SG rules simpler, for example they want a /28 of FIPs than can be specified as a range instead of individually. Something like that.

And just adding to my last comment, some of this was because the remote end - say a customer VPN appliance - had to be programmed. Out of convenience a range is easy, individual IPs are harder.

This could just be an outlier case though.

@Doug: to allow more than one client application to benefit from the change.

@Brian: either you program ranges or single IPs, this can't be done manually, so where is the complexity coming from?

Need for contiguous FIPs determines whether this must be done server side or client side, allowing users to reserve wide blocks of FIPs can become an issue with multiple competing requests at scale.

Status update:

http://eavesdrop.openstack.org/meetings/neutron_drivers/2016/neutron_drivers.2016-03-31-22.00.log.html#l-187

In my understanding, the original request from Horizon is just to request a way to allocate multiple floating IPs. For this, client library support sounds good.

For contiguous range of FIPs, I understand the need to some extent, but users need a fallback logic when allocation of a range of FIPs, so I am not sure how much this feature helps users.
In addition, our current API provides no way to discover whether neutron supports a range allocation FIPs (without trying to send a request).

In keeping with the current transition of NeutronClient to OSC, I think any change in neutronClient for this support would need a corresponding change in OSC.

neutronclient has two layers: client library and CLI.
We are discussing enhancement in the client library and potentially CLI layer can be enhanced.

Regarding OSC support, neutronclient is not directly related. openstack client consumes openstacksdk for core resources like floating IP. Especially floating IP is related to both neutron and nova (nova-network), so I would suggest to work openstackclient stuff in a separate bug.

ok, let's go with client-side support.

This is relatively trivial and can be dealt with as a client side bug fix.

Automatically unassigning due to inactivity.

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

Removing Horizon here; this is just dead weight until clients support it. We can revisit the idea in the future if a service decides to implement it.

neutron cli is deprecated. we no longer add new features.