[RFE] Support creating a subnet without an allocation pool

[James Denton]

Problem Description
===================

Currently, subnets are created with an allocation pool(s) that is either a) user-defined or b) automatically generated based on CIDR. This RFE asks that the community support the creation of subnets without an allocation pool.

Neutron allows users to create ports using fixed IP addresses that fall outside of the subnet allocation pool(s) but within the range defined by the CIDR. Neutron keeps track of assigned addresses and does not allow for overlap within the same subnet.

Use cases:
* An external IPAM service is utilized that is not integrated with OpenStack/Neutron. The user wants to create a port with a specific IP address using the --fixed-ip flag, and does not want Neutron automatically consuming addresses from the pool if an address is not manually allocated via Neutron or Nova.

Proposed Change
===============

Allow 'None', or similar value, as a valid start/end value. The result would be that Neutron would not create an allocation pool for the subnet. The Neutron client would have a new flag, such as --no-allocation-pool, or something similar.

As I see it, not creating an allocation pool for a subnet would mean that when a port is created without an IP specified, Neutron would return the 'no more addresses available for allocation' error. Otherwise, the current behavior of allowing the user to specify a particular fixed IP address remains the same.

[Armando Migliaccio (armando-migliaccio)]

Bear in mind that we're getting super busy in time for feature freeze, and we're not processing RFEs at this point.

[Kevin Carter (kevin-carter)]

+1 this would be a great option to have.

[Buck Wallander (buck-wallander)]

+1

[Luke Yildirim (luke.yildirim)]

+1 this would a great feature.

[Carl Baldwin (carl-baldwin)]

It would've been nice if passing [] for allocation_pools in a subnet create did this. But, it doesn't, it generates the automatic pool.

For API backward compatibility, we'd have to add something else to trigger an empty allocation pool. This is unfortunate but I've had enough experience to know that trying to slip it in without an API change is just going to end in tears. :'(

For now, you can work around this by creating the subnet and then following up with PUT to http://{{neutron_ip}}:9696/v2.0/subnets/{{subnet_id}} with this in the body:

  {"subnet": {"allocation_pools": []}}

I doubt the client supports this yet. So, maybe someone could enhance the client to allow this.

[James Denton (james-denton)]

Thanks for the tip, Carl! If it works, it'll certainly fill the gap until a more graceful solution comes along.

[Armando Migliaccio (armando-migliaccio)]

Any feedback on the suggestion made by Carl?

[James Denton (james-denton)]

Hi Armando,

Sorry for the late reply here. Carl's workaround does work, and is fine for us since we're making calls to Neutron without the client. Thanks for the followup.

[Armando Migliaccio (armando-migliaccio)]

We should see if the OSC client allows the specification of *no allocation pools* as suggested by Carl on comment #5. Excerpt below:

For now, you can work around this by creating the subnet and then following up with PUT to http://{{neutron_ip}}:9696/v2.0/subnets/{{subnet_id}} with this in the body:

  {"subnet": {"allocation_pools": []}}

I doubt the client supports this yet. So, maybe someone could enhance the client to allow this.

[OpenStack Infra (hudson-openstack)]

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

[Sindhu Devale (sindhu-devale-3)]

@Armando: hey, I started working on this bug https://review.openstack.org/#/c/433234/, is this bug invalid?

[OpenStack Infra (hudson-openstack)]

Change abandoned by Armando Migliaccio (<email address hidden>) on branch: master
Review: https://review.openstack.org/433234
Reason: This review is > 3 months without comment and currently blocked by a core reviewer with a -1. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and contacting the reviewer with the -1 on this review to ensure you address their concerns.

[Slawek Kaplonski (slaweq)]

@James: Are You still interested in this RFE and would You maybe like to work on implementation of this in Victoria cycle? Should we discuss that in drivers meeting?

[James Denton (james-denton)]

@Slawek - Yes, I'd still be interested in solving this, although the immediate need has subsided. I will try to make the Drivers meetings and we can chat about it. Thanks!

[Slawek Kaplonski (slaweq)]

Ok, thx James for confirmation.
I think we can then bring this to the next drivers meeting.

[Slawek Kaplonski (slaweq)]

We discussed this RFE on our last drivers meeting: http://eavesdrop.openstack.org/meetings/neutron_drivers/2020/neutron_drivers.2020-04-24-14.00.log.html and we all agreed to approve this RFE and add possibility to send "null" as allocation_pools in POST request for subnets.
@James, are You going to work on implementation of this RFE?

[Rodolfo Alonso (rodolfo-alonso-hernandez)]

Bug closed due to lack of activity, please feel free to reopen if needed.