Open Stack

Honestly, I'm a little frustrated that this is coming up now when we
tried very hard to discuss this during the spec review and we thought
we got to a resolution.  It seems a little late to go back to the
drawing board.

On Mon, Mar 9, 2015 at 7:05 AM, Salvatore Orlando <sorlando at nicira.com> wrote:
> The problem with this approach is, in my opinion, that attributes such as
> gateway_ip are used with different semantics in requests and responses; this
> might also need users to write client applications expecting the values in
> the response might differ from those in the request.

Is this so strange?  Could you explain why this is a problem with an example?

> 1) (this is more for neutron people) Is there a real use case for requesting
> specific gateway IPs and allocation pools when allocating from a pool? If
> not, maybe we should let the pool set a default gateway IP and allocation
> pools. The user can then update them with another call. Another option would
> be to provide "subnet templates" from which a user can choose. For instance
> one template could have the gateway as first IP, and then a single pool for
> the rest of the CIDR.

If you really don't like this aspect of the design then my vote will
be to drop support for this use case for Kilo.  Neutron will specify
gateway and allocation pools from the subnet and maybe the user can
update the subnet afterward if it needs to change.

> 2) Is the action of creating a subnet from a pool better realized as a
> different way of creating a subnet, or should there be some sort of "pool
> action"? Eg.:

I think this shift in direction will push this work entirely out to
Liberty.  We have one week until Kilo-3.

Carl