<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">2015-07-15 22:57 GMT+08:00 Matt Riedemann <span dir="ltr"><<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class=""><br>
<br>
On 7/15/2015 3:24 AM, Alex Xu wrote:<br>
</span><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
2015-07-15 5:14 GMT+08:00 Matt Riedemann <<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a><br></span>
<mailto:<a href="mailto:mriedem@linux.vnet.ibm.com" target="_blank">mriedem@linux.vnet.ibm.com</a>>>:<div><div class="h5"><br>
<br>
<br>
<br>
On 7/14/2015 3:43 PM, Cale Rath wrote:<br>
<br>
Hi,<br>
<br>
I created a patch to fail on the proxy call to Neutron for used<br>
limits,<br>
found here: <a href="https://review.openstack.org/#/c/199604/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/199604/</a><br>
<br>
This patch was done because of this:<br>
<a href="http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies" rel="noreferrer" target="_blank">http://docs.openstack.org/developer/nova/project_scope.html?highlight=proxy#no-more-api-proxies</a>,<br>
where it’s stated that Nova shouldn’t be proxying API calls.<br>
<br>
That said, Matt Riedemann brings up the point that this breaks<br>
the case<br>
where Neutron is installed and we want to be more graceful,<br>
rather than<br>
just raising an exception. Here are some options:<br>
<br>
1. fail - (the code in the patch above)<br>
2. proxy to neutron for floating ips and security groups -<br>
that's what<br>
the original change was doing back in havana<br>
3. return -1 or something for floatingips/security groups to<br>
indicate<br>
that we don't know, you have to get those from neutron<br>
<br>
Does anybody have an opinion on which option we should do<br>
regarding API<br>
proxies in this case?<br>
<br>
Thanks,<br>
<br>
Cale Rath<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<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></div></div>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><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>
<br>
<br>
I prefer the proxy option, despite that we don't want to do more<br>
proxies to other services, it's the least of all evils here in my<br>
opinion.<br>
<br>
I don't think we can do #1, that breaks anyone using those APIs and<br>
is using Neutron, so it's a non-starter.<br>
<br>
<br>
agree<br>
<br>
<br>
#3 is an API change in semantics which would at least be a<br>
microversion and is kind of clunky.<br>
<br>
<br>
agree too~<br>
<br>
<br>
For #2 we at least have the nova.network.base_api which we didn't<br>
have in Havana when I was originally working on this, that would<br>
abstract the neutron-specific cruft out of the nova-api code. The<br>
calls to neutron were pretty simple from what I remember - we could<br>
just resurrect the old patch:<br>
<br>
<a href="https://review.openstack.org/#/c/43822/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/43822/</a><br>
<br>
<br>
+1, but looks like this need new microversion also. It means after 2.x<br>
version, this api value is valid for neutron, before 2.x version, don't<br>
trust this api...<br>
</span></blockquote>
<br>
I'm not exactly clear on why we couldn't implement this as a bug fix for v2.0? I guess because of the standard reason we give for all microversions which is discoverability.<br></blockquote><div><br></div><div>yes...It is the standard reason</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
I guess in the v2.0 case we could just log the warning (option 4). It's not great, but at least it's a thing that an operator could find if they are using v2.0 and expecting proper quotas/limits values for security groups and floating IPs when using neutron but talking to the nova-api.<br></blockquote><div><br></div><div>This info is more important for API user, so API doc is enough?</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
<br>
<br>
<br>
Another option is #4, we mark the bug as won't fix and we log a<br>
warning if neutron is configured saying some of the resources aren't<br>
going to be correct, use the neutron API to get information for<br>
quotas on security groups, floating IPs, etc. That's also kind of<br>
gross IMO, but it's an option.<br>
<br>
<br>
if we plan to deprecate network proxy api in no longer future, this is<br>
easy option.<br>
<br>
<br>
<br>
--<br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<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></span>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://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><span class=""><br>
<br>
<br>
<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>
<br>
</span></blockquote><div class="HOEnZb"><div class="h5">
<br>
-- <br>
<br>
Thanks,<br>
<br>
Matt Riedemann<br>
<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>