[openstack-dev] [api][neutron] Best API for generating subnets from pool

Carl Baldwin carl at ecbaldwin.net
Tue Mar 10 17:51:45 UTC 2015

On Mon, Mar 9, 2015 at 5:34 PM, Tidwell, Ryan <ryan.tidwell at hp.com> wrote:
> With implicit allocations, the thinking is that this is where a subnet is
> created in a backward-compatible way with no subnetpool_id and the subnets
> API’s continue to work as they always have.


> In the case of a specific subnet allocation request (create-subnet passing a
> pool ID and specific CIDR), I would look in the pool’s available prefix list
> and carve out a subnet from one of those prefixes and ask for it to be
> reserved for me.  In that case I know the CIDR I’ll be getting up front.  In
> such a case, I’m not sure I’d ever specify my gateway using notation like
>, even if I was allowed to.  If I know I’ll be getting,
> I can simply pass gateway_ip as and be done with it.  I see no
> added value in supporting that wildcard notation for a gateway on a specific
> subnet allocation.

Correct.  Not what it was designed for.

> In the case of an “any” subnet allocation request (create-subnet passing a
> pool ID, but no specific CIDR), I’m already delegating responsibility for
> addressing my subnet to Neutron.  As such, it seems reasonable to not have
> strong opinions about details like gateway_ip when making the request to
> create a subnet in this manner.

I'm okay dropping this use case if we need to.

> To me, this all points to not supporting wildcards for gateway_ip and
> allocation_pools on subnet create (even though it found its way into the
> spec).  My opinion (which I think lines up with yours) is that on an any
> request it makes sense to let the pool fill in allocation_pools and
> gateway_ip when requesting an “any” allocation from a subnet pool.  When
> creating a specific subnet from a pool, gateway IP and allocation pools
> could still be passed explicitly by the user.

If this is what we need to do.  I don't think there is high demand for
this use case.


More information about the OpenStack-dev mailing list