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.
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.
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
