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