Open Stack

On 4/19/2016 5:59 PM, Armando M. wrote:
>
>
> On 18 April 2016 at 15:41, Jay Pipes <jaypipes at gmail.com
> <mailto:jaypipes at gmail.com>> wrote:
>
>     On 04/18/2016 04:33 PM, Sean Dague wrote:
>
>         When doing bug triage this morning a few bugs popped up:
>
>         - https://bugs.launchpad.net/nova/+bug/1456899 - nova
>         absolute-limits
>         Security groups count incorrect when using Neutron
>         - https://bugs.launchpad.net/nova/+bug/1376316 - nova
>         absolute-limits
>         floating ip count is incorrect in a neutron based deployment
>         - https://bugs.launchpad.net/nova/+bug/1456897 - nova
>         absolute-limits
>         Floating ip
>
>         The crux of this is the Nova limits API basically returns junk about
>         resources it doesn't own. It's been this way forever.
>
>         Last year there was a spec to add proxying to Neutron to the
>         Nova API -
>         https://review.openstack.org/#/c/206735/ - which died on the vine.
>
>
>         I think we've moved to a point in time where we need to stop
>         thinking
>         about nova-net / neutron parity in our API. Neutron is the
>         predominate
>         stack out there. Where things don't work correctly with Neutron
>         from our
>         proxy API we should start saying "yes, that's not supported,
>         please go
>         talk to Neutron" one way or another.
>
>         I feel like in this case it would be dropping the keys which we
>         know are
>         lies (terrible lies). If using OpenStack client, it can smooth over
>         this. In general, people should assume they should be talking to
>         neutron
>         when getting this kind of data. I feel like in other cases where we
>         don't return good neutron data today, we should accept that as
>         status
>         quo, and not fix it.
>
>         I'd like to propose an alternative spec which is this kind of
>         approach,
>         to by policy not enhance any of the proxies and instead focus on
>         ways in
>         which we can aggressively deprecate them. But figured it was worth
>         discussion first. Flame away!
>
>
>     +1 to killing off all API proxying in the Compute API. Notably: the
>     Images API proxy should die in a fire of obsolescence.
>
>
> The proxy APIs in Nova (spanning volume, image and networks) should all
> be consistently dealt with. I appreciate that volume != image !=
> network, but I hope we can get to a point in the future where all
> non-compute APIs are no longer part of the (compute) API, and only those
> that do some non-negligible orchestration are left included (e.g.
> attach/detach volume|interface)?
>
>
>
>     Also note that the "absolute-limits" API I actually believe should
>     be in Keystone and that would make its existence in Nova be a proxy
>     and therefore it, too, long-term should be thrown off the cliffs of
>     deprecation into the sea of redundancy.
>
>     -jay
>
>
>     __________________________________________________________________________
>     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
>

I've always personally considered the network proxy to neutron in the 
API as getting more of a pass since nova has a network service in it, it 
doesn't have it's own image or volume service since those were 
completely split out. But since the adoption rate for neutron has taken 
off, it does make less sense to put effort into filling the API gaps 
with new proxy code.

-- 

Thanks,

Matt Riedemann