Open Stack

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