On 7/15/2015 4:22 AM, Salvatore Orlando wrote:
Some comments inline.
Salvatore
On 15 July 2015 at 10:24, Alex Xu <[email protected]
<mailto:[email protected]>> wrote:
2015-07-15 5:14 GMT+08:00 Matt Riedemann <[email protected]
<mailto:[email protected]>>:
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:
[email protected]?subject:unsubscribe
<http://[email protected]?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.
Yeah, good point on the -1 for unlimited quota, that's how it's treated
in nova also.
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:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
[email protected]?subject:unsubscribe
<http://[email protected]?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
--
Thanks,
Matt Riedemann
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: [email protected]?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
