mriedem at linux.vnet.ibm.com
Wed Jul 15 15:00:06 UTC 2015
On 7/15/2015 5:41 AM, John Garbutt wrote:
> On 14 July 2015 at 21:43, Cale Rath <ctrath at linux.vnet.ibm.com> wrote:
>> 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:
>> 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.
> +1 to matt's point.
>> 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?
> We need to have our APIs work the same using either nova-network or
> neutron, to keep the API interoperable.
> The scope document is really trying to say that adding new APIs that
> force us to do more proxying would be bad (e.g. passing in extra
> properties for the ports that Nova creates in neutron on behalf of the
> In this case, it seems we need to proxy to neutron to ensure the Nova
> API keeps working as expected when you use Neutron.
> Its possible there is a massive gotcha I am just not seeing right now?
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
I don't think you're missing anything. It's a pretty clear case. The
reason this hasn't been fixed for so long is that originally back in
Havana with the nova v3 API we expected to drop all proxy code to
neutron so it wouldn't even be a problem in the new v3 API, at least
that was the thinking. Then things changed, we just never got back
around to closing this gap.
More information about the OpenStack-dev