On 4/18/2016 3: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! -Sean
I guess at a high level my thinking was always, if nova-network isn't deprecated, and these APIs are broken when using Neutron, it's (mostly) trivial to add a proxy to fill those gaps (like my spec for os-virtual-interfaces). So then when people move from deprecated nova-network to neutron, all of their tooling doesn't start breaking.
In thinking about it another way, if we just say nova-network is deprecated again and therefore we have no incentive to make these APIs work in the Neutron case, and want to force people off them, then I can see that point.
It was different back in Havana when I was originally looking at this because Neutron adoption was very different. With the recent survey, however, it looks like nova-network is 7% of deployments now, and that's including non-production. So I concede that it's making less sense to put effort into making the APIs work with a proxy.
-- Thanks, Matt Riedemann __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
