On 18 April 2016 at 15:41, Jay Pipes <[email protected]> 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: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
