Open Stack

2015-07-15 22:57 GMT+08:00 Matt Riedemann <mriedem at linux.vnet.ibm.com>:

>
>
> On 7/15/2015 3:24 AM, Alex Xu wrote:
>
>>
>>
>> 2015-07-15 5:14 GMT+08:00 Matt Riedemann <mriedem at linux.vnet.ibm.com
>> <mailto: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://OpenStack-dev-request@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.
>

yes...It is the standard reason


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

This info is more important for API user, so API doc is enough?


>
>
>>
>>
>>     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-request at lists.openstack.org?subject:unsubscribe
>>     <http://OpenStack-dev-request@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
>>
>>
> --
>
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150716/f1fbfe5d/attachment-0001.html>