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

John Belamaric jbelamaric at infoblox.com
Mon Mar 23 14:52:50 UTC 2015


On 3/21/15, 9:10 AM, "Salvatore Orlando" <sorlando at nicira.com<mailto:sorlando at nicira.com>> wrote:

If we feel a need for specifying the relative position of gateway address and allocation pools when creating a subnet from a pool which will pick a CIDR from its prefixes, then the integer value solution is probably marginally better than the "fake IP" one (eg.: 0.0.0.1 to say the gateway is the first IP). Technically they're equivalent - and one could claim that the address-like notation is nothing bug and octet based representation of a number.

I agree here. An integer is probably clearer.


I wonder why a user would ask for a random CIDR with a given prefix, and then mandate that gateway IP and allocation pools are in precise locations within this randomly chosen CIDR. I guess there are good reasons I cannot figure out by myself.

Early in the spec review cycle we talked about some generalizations of these concepts. I would consider the location of the gateway IP to be a reservation; we discussed having subnet templates that (in my mind) are essentially a collection of IP reservations. This would allow a user to specify the specific locations of various services in a pre-defined manner; routing is just one of those services that is prominent as a specific case for backwards compatibility.

In my opinion all that counts here is that the semantics of a resource attribute should be the same in the request and the response. For instance, one should not have gateway_ip as a relative "counter-like" IP in the request body and then as an actual IP address in the response object.

So, you are agreeing with an alternate name in the request, as suggested?

John

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150323/10d0da8e/attachment.html>


More information about the OpenStack-dev mailing list