On 3/21/15, 9:10 AM, "Salvatore Orlando" <sorla...@nicira.com<mailto:sorla...@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
__________________________________________________________________________ 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
