<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 18 April 2016 at 15:41, Jay Pipes <span dir="ltr"><<a href="mailto:jaypipes@gmail.com" target="_blank">jaypipes@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div><div>On 04/18/2016 04:33 PM, Sean Dague wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
When doing bug triage this morning a few bugs popped up:<br>
<br>
- <a href="https://bugs.launchpad.net/nova/+bug/1456899" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1456899</a> - nova absolute-limits<br>
Security groups count incorrect when using Neutron<br>
- <a href="https://bugs.launchpad.net/nova/+bug/1376316" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1376316</a> - nova absolute-limits<br>
floating ip count is incorrect in a neutron based deployment<br>
- <a href="https://bugs.launchpad.net/nova/+bug/1456897" rel="noreferrer" target="_blank">https://bugs.launchpad.net/nova/+bug/1456897</a> - nova absolute-limits<br>
Floating ip<br>
<br>
The crux of this is the Nova limits API basically returns junk about<br>
resources it doesn't own. It's been this way forever.<br>
<br>
Last year there was a spec to add proxying to Neutron to the Nova API -<br>
<a href="https://review.openstack.org/#/c/206735/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/206735/</a> - which died on the vine.<br>
<br>
<br>
I think we've moved to a point in time where we need to stop thinking<br>
about nova-net / neutron parity in our API. Neutron is the predominate<br>
stack out there. Where things don't work correctly with Neutron from our<br>
proxy API we should start saying "yes, that's not supported, please go<br>
talk to Neutron" one way or another.<br>
<br>
I feel like in this case it would be dropping the keys which we know are<br>
lies (terrible lies). If using OpenStack client, it can smooth over<br>
this. In general, people should assume they should be talking to neutron<br>
when getting this kind of data. I feel like in other cases where we<br>
don't return good neutron data today, we should accept that as status<br>
quo, and not fix it.<br>
<br>
I'd like to propose an alternative spec which is this kind of approach,<br>
to by policy not enhance any of the proxies and instead focus on ways in<br>
which we can aggressively deprecate them. But figured it was worth<br>
discussion first. Flame away!<br>
</blockquote>
<br></div></div>
+1 to killing off all API proxying in the Compute API. Notably: the Images API proxy should die in a fire of obsolescence.<br></blockquote><div><br></div><div>The proxy APIs in Nova (spanning volume, image and networks) should all be consistently dealt with. I appreciate that volume != image != network, but I hope we can get to a point in the future where all non-compute APIs are no longer part of the (compute) API, and only those that do some non-negligible orchestration are left included (e.g. attach/detach volume|interface)?</div><div>  </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Also note that the "absolute-limits" API I actually believe should be in Keystone and that would make its existence in Nova be a proxy and therefore it, too, long-term should be thrown off the cliffs of deprecation into the sea of redundancy.<span><font color="#888888"><br>
<br>
-jay</font></span><div><div><br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div>