Open Stack

On 10 March 2015 at 16:48, Carl Baldwin <carl at ecbaldwin.net> wrote:

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

I guess that frustration has now become part of the norm for Openstack.
It is not the first time I frustrate people because I ask to reconsider
decisions approved in specifications.
This is probably bad behaviour on my side. Anyway, I'm not suggesting to go
back to the drawing board, merely trying to get larger feedback, especially
since that patch should always have had the ApiImpact flag.
Needless to say, I'm happy to proceed with things as they've been agreed.


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

There is nothing intrinsically wrong with it - in the sense that it does
not impact the functional behaviour of the system.
My comment is about RESTful API guidelines. What we pass to/from the API
endpoint is a resource, in this case the subnet being created.
You expect gateway_ip to be always one thing - a gateway address, whereas
with the wildcarded design it could be an address or an incremental counter
within a range, but with the counter being valid only in request objects.
Differences in entities between requests and response are however fairly
common in RESTful APIs, so if the wildcards sastisfy a concrete and valid
use case I will stop complaining, but I'm not sure I see any use case for
wildcarded gateways and allocation pools.


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

I reckon Ryan is of the same advice as well. The point is not about what I
like or not. Nobody care about that.
The point is whether this really makes sense or not. If you already have
use cases for using such wildcards then we'll look at supporting them.


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

One week is barely enough for code review alone.
But code-wise implementing support for a slightly different API is fairly
simple.
Also, there might also be backward-compatible ways of switching from one
approach to another, in which case I'm happy to keep things as they are and
relieve Ryan from yet another worry.


>
> Carl
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150310/4f5a76eb/attachment.html>