Open Stack

On 7/15/2015 4:22 AM, Salvatore Orlando wrote:
> Some comments inline.
>
> Salvatore
>
> On 15 July 2015 at 10:24, Alex Xu <soulxu at gmail.com
> <mailto:soulxu at gmail.com>> 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~
>
>
> Also it overlaps with Neutron semantics of returning -1 for "unlimited"
> and it could be misinterpreted.

Yeah, good point on the -1 for unlimited quota, that's how it's treated 
in nova also.

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