Open Stack

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

I also agree wilcards do not look solid, and without clear use cases
with reasonable demand from operators, it's better to avoid putting
ourselves into position of supporting the feature for eternity.

We had cases of immature API design rushed into the tree before
(particularly, ipv6 ra|addr modes for subnets) resulting in long fire
fighting and confusing behaviour that we're stuck in, and it's better
to avoid it here if possible.

/Ihar

On 03/10/2015 09:03 PM, Tidwell, Ryan wrote:
> 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
> 
> __________________________________________________________________________
>
> 
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
> 
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1

iQEcBAEBAgAGBQJVAMFWAAoJEC5aWaUY1u57p3IH/j3PQgbQS/g1r1xjCvLT0Dmx
T25VBtT+jercZMd7Xe+isY1nhwmCOnlZH27ZwviIz6HIfL/t2qyyrW/B5t9ZiL49
kYDd2SXcxGm/qSiSV99hPMR5vVLC57PzAjwjoFoNebodbYDwqTb00jYcA/+JLgrm
LQxisvo7C3QBSd+/xAyDCy4Y62B6RFvcYItmBVN2shbPkseNrJk3+jnoK0qxzOXa
FyOecP1hi+W0OuR7SCEi8BBYvKSGDJ977I1+B3tUsfjBOxW1Ay5Llb3X3CfM4Xks
XHA+W43lJtgz1CtK1ur906gkrNnT5ve95oxdiXj+fAl27zNUqqqKWjbt2ecbWHg=
=+PU9
-----END PGP SIGNATURE-----