Open Stack

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.

Correct.

> 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
> 0.0.0.1, even if I was allowed to.  If I know I’ll be getting 10.10.10.0/24,
> I can simply pass gateway_ip as 10.10.10.1 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.

Carl