[openstack-dev] [api][neutron] Best API for generating subnets from pool

Carl Baldwin carl at ecbaldwin.net
Tue Mar 10 18:43:58 UTC 2015

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.


More information about the OpenStack-dev mailing list