[openstack-dev] [nova] [neutron] the nova network facade that isn't

Monty Taylor mordred at inaugust.com
Tue Apr 19 20:18:15 UTC 2016

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.


>> 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.


More information about the OpenStack-dev mailing list