<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 10 March 2015 at 16:48, Carl Baldwin <span dir="ltr"><<a href="mailto:carl@ecbaldwin.net" target="_blank">carl@ecbaldwin.net</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Honestly, I'm a little frustrated that this is coming up now when we<br>
tried very hard to discuss this during the spec review and we thought<br>
we got to a resolution. It seems a little late to go back to the<br>
drawing board.<br></blockquote><div><br></div><div>I guess that frustration has now become part of the norm for Openstack.</div><div>It is not the first time I frustrate people because I ask to reconsider decisions approved in specifications.</div><div>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.</div><div>Needless to say, I'm happy to proceed with things as they've been agreed.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
On Mon, Mar 9, 2015 at 7:05 AM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
> The problem with this approach is, in my opinion, that attributes such as<br>
> gateway_ip are used with different semantics in requests and responses; this<br>
> might also need users to write client applications expecting the values in<br>
> the response might differ from those in the request.<br>
<br>
</span>Is this so strange? Could you explain why this is a problem with an example?<br></blockquote><div><br></div><div>There is nothing intrinsically wrong with it - in the sense that it does not impact the functional behaviour of the system.</div><div>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.</div><div>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.</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 1) (this is more for neutron people) Is there a real use case for requesting<br>
> specific gateway IPs and allocation pools when allocating from a pool? If<br>
> not, maybe we should let the pool set a default gateway IP and allocation<br>
> pools. The user can then update them with another call. Another option would<br>
> be to provide "subnet templates" from which a user can choose. For instance<br>
> one template could have the gateway as first IP, and then a single pool for<br>
> the rest of the CIDR.<br>
<br>
</span>If you really don't like this aspect of the design then my vote will<br>
be to drop support for this use case for Kilo. Neutron will specify<br>
gateway and allocation pools from the subnet and maybe the user can<br>
update the subnet afterward if it needs to change.<br></blockquote><div><br></div><div>I reckon Ryan is of the same advice as well. The point is not about what I like or not. Nobody care about that.</div><div>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.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
> 2) Is the action of creating a subnet from a pool better realized as a<br>
> different way of creating a subnet, or should there be some sort of "pool<br>
> action"? Eg.:<br>
<br>
</span>I think this shift in direction will push this work entirely out to<br>
Liberty. We have one week until Kilo-3.<br></blockquote><div><br></div><div>One week is barely enough for code review alone.</div><div>But code-wise implementing support for a slightly different API is fairly simple.</div><div>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.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class="HOEnZb"><font color="#888888"><br>
Carl<br>
</font></span><div class="HOEnZb"><div class="h5"><br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>