On Mon, Mar 9, 2015 at 5:34 PM, Tidwell, Ryan <ryan.tidw...@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 __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
