Open Stack

Just to be clear (As I think the conversation is getting muddled here) there are two independent API extensions that are proxied to quantum:

Security Groups - Quantum has features that Nova doesn't.   The API is in effect purely a pass through (with some limited mapping) to Quantum

Floating IPs - Quantum and Nova have the same features.    The API is more than a pass through as it also triggers a refresh of the cached data in Nova

The discussion round Egress rules is purely about the Security Groups API extension.     This extension could be removed from Nova with no loss of functionality (just use the Quantum API), but with a loss of backwards compatibility to user migrating from a Nova Network based system (which is why that isn't an attractive proposition to me).

The Floating IP extension doesn't need to be changed - but can't be removed either in favour of just working with the Quantum API unless we will at the same tiem remove the network info caching in Nova.

> So.. What about having the floating-ip extension return a "Please Use Quantum" error if it encounters as Quantum specific feature in-use?    
It would be the SecGroup API - and if we have to extend it to do that we may as well make it cover the Quantum functionality

>Extending nova's floating IP extension to support, for example, egress rules will likely cause confusion for those who are still on nova-network.. In other words, I think the potential confusion goes both ways.

I don't think it would - on Nova network it would show (correctly) that there are no egress rules, and (correctly) prevent you from creating any.   The problem at the moment is that it (incorrectly) doesn't show you that there are egress rules in place when using Quantum.

I did think about just showing Egress rules but not providing support to create them - but that could be even more confusing because you either have to add to the API to allow the direction to be specified and then reject it (but which point you may as well process it), or have it silently igniored in which case you would end up with an inbound rule you didn't want.

Phil 

-----Original Message-----
From: Mac Innes, Kiall 
Sent: 05 June 2013 15:17
To: OpenStack Development Mailing List
Cc: Day, Phil
Subject: Re: [openstack-dev] Make Secgroup extension fully compatible with Quantum as part of V3

On 05/06/13 14:30, Day, Phil wrote:
> 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.
So.. What about having the floating-ip extension return a "Please Use Quantum" error if it encounters as Quantum specific feature in-use?

Extending nova's floating IP extension to support, for example, egress rules will likely cause confusion for those who are still on nova-network.. In other words, I think the potential confusion goes both ways.

Thanks,
Kiall