Open Stack

On 18 April 2016 at 15:41, Jay Pipes <jaypipes at gmail.com> 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.
>

The proxy APIs in Nova (spanning volume, image and networks) should all be
consistently dealt with. I appreciate that volume != image != network, but
I hope we can get to a point in the future where all non-compute APIs are
no longer part of the (compute) API, and only those that do some
non-negligible orchestration are left included (e.g. attach/detach
volume|interface)?


>
> 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
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160419/d263f3f4/attachment-0001.html>