Open Stack

Some comments inline.

Salvatore

On 15 July 2015 at 10:24, Alex Xu <soulxu at gmail.com> wrote:

>
>
> 2015-07-15 5:14 GMT+08:00 Matt Riedemann <mriedem at 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-request at 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150715/e77bf162/attachment.html>