Open Stack

I agree with dropping support for the wildcards.  It can always be revisited at later. I agree that being locked into backward compatibility with a design that we really haven't thought through is a good thing to avoid.  Most importantly (to me anyway) is that this will help in getting subnet allocation completed for Kilo. We can iterate on it later, but at least the base functionality will be there.

-Ryan

-----Original Message-----
From: Carl Baldwin [mailto:carl at ecbaldwin.net] 
Sent: Tuesday, March 10, 2015 11:44 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [api][neutron] Best API for generating subnets from pool

On Tue, Mar 10, 2015 at 12:24 PM, Salvatore Orlando <sorlando at nicira.com> wrote:
> 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.

I'm okay revisiting decisions.  It is just the timing that is difficult.

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

It did have the ApiImpact flag since PS1 [1].

> Needless to say, I'm happy to proceed with things as they've been agreed.

I'm happy to discuss and I value your input very highly.  I was just
hoping that it had come at a better time to react.

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

Let's drop the use case and the wildcards as we've discussed.

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

I think dropping the use case for now allows us the most freedom and
doesn't commit us to supporting backward compatibility for a decision
that may end up proving to be a mistake in API design.

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