On 04/18/2016 05:41 PM, Jay Pipes 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.
GOD YES
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.
yes
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.
yes
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.
++
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
