Open Stack

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.

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