Open Stack

-----Original Message-----
From: Russell Bryant [mailto:rbryant at redhat.com] 
Sent: 31 May 2013 21:14
To: openstack-dev at lists.openstack.org
Subject: Re: [openstack-dev] Make Secgroup extension fully compatible with Quantum as part of V3

On 05/31/2013 01:47 PM, Day, Phil wrote:
>>>>
>>>> I'm curious about this too. I'm hoping that in the nova v3 api we 
>>>> can remove security groups and networking from an instance and 
>>>> leaving all the information in quantum for the client to query directly.
>> 
>>> Yeah, I was actually hoping we could make v3 effectively quantum-only, and remove deprecated network stuff that should be done in quantum.
>> 
>> I can see the logic, but as I understand it we will only announce nova-networking as deprecated at the start of I - so to my way of thinking that means
>>that we need to continue to support network APIs in Nova until at least the J release.    That's a long time to have people getting in a tangle because
>>they can only see half of the secgroup rules through nova.   Maybe I need to think about this as a v2 extension-extension then ?

>Well, if all went perfectly, we'd mark nova-network as deprecated in Havana.  If that's not going to happen, then you can scratch what I said and we
> might as well carry all of the networking stuff into the v3.

So if it gets marked as deprecated in the Havana release that means it won't be removed until the I release (i.e the end of the I cycle) is that right ?  If so we still have at least the best part of a year left with these extensions.

I'm assuming that even if nova-network is deprecated the floating-ip extension will still be carried forwards, because unless we drop the caching of network info in Nova assigning addresses directly to ports in Quantum  causes all sorts of confusion when looking at server details (unless we're only going to display the port uuid going forward) ? 


>Either way, I'm not sure it makes a whole lot of sense to extend nova's view for quantum-specific features.  Why not just use the quantum APIs and disable the >equivalent parts of the nova API?

I get the sentiment, but the use case I'm trying to cover is providing a backward compatible set of APIs for folks moving from a nova-network system to a quantum system.   The idea is that they can keep using the APIs they are used to / have apps written against until they are ready to start using the advanced features from quantum.   The problem we hit is that as soon as someone within a project starts to use features that are only exposed in the quantum API it can get really confusing for the folks that haven't moved yet.    I know they should just stick with one or t'other, but some users are a tad unpredictable at times, and they get cross when they spend a lot of time trying to track this kinds of issues down.

If there's no interest at all and others don't think they'll have the same issue then I'll just let it go

Cheers,
Phil


_______________________________________________
OpenStack-dev mailing list
OpenStack-dev at lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev