Open Stack

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.

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