On Tue, Mar 10, 2015 at 12:24 PM, Salvatore Orlando <sorla...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev