Some comments inline. Salvatore
On 15 July 2015 at 10:24, Alex Xu <sou...@gmail.com> wrote: > > > 2015-07-15 5:14 GMT+08:00 Matt Riedemann <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://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~ > Also it overlaps with Neutron semantics of returning -1 for "unlimited" and it could be misinterpreted. > > >> >> 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... > This is correct, and makes sense in my opinion. Still, I agree more that the final goal should be to stop proxying this calls. #2 is in my opinion a good strategy for transitioning to #1. I am not sure whether it is acceptable to just document that retrieving limits in Nova for resources managed by other projects is deprecated and will not be allowed anymore in M or N. > > >> >> >> 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. > I am not sure this is a good option. The warning in this case should be returned to the user making the limits request; logging it just tells the operator somebody has retrieved limits using a proxy. > >> >> >> -- >> >> 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 > >
__________________________________________________________________________ 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