Open Stack

On Mon, Mar 23, 2015 at 8:52 AM, John Belamaric <jbelamaric at infoblox.com> wrote:
>
> On 3/21/15, 9:10 AM, "Salvatore Orlando" <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 don't agree.  I don't see what problem this solves but I said that
in another message.

> 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.

Salvatore makes a good point.  Maybe we'll never need this.  We
removed the use case from Kilo because it needed further discussion.
At this point, let's look for people to speak up with a need for this
use case.  If no one does, then we just leave it on the shelf.  That
has been my thinking since we dropped it but I figured the thread
should continue to play itself out because it doesn't hurt to discuss
it a little more here.

> 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.

I figure some users may like to have a consistent pattern for how to
reserve parts of a subnet regardless of the network address.  So, I
agree with John here.  It is really orthogonal to the specific network
address used.  I don't quite agree with Salvatore that not caring what
the network address is implies that one does not care how some
routinely reserved special IPs get laid out within a subnet.  However,
I do tend to agree that the use case may not be all that important.

> 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.

In my opinion, we have solved this by using some other -- write-only
-- attribute for the template, index, or whatever you want to call it.
Thanks Jay for this suggestion.

Carl