Open Stack

On 05/30/2013 01:35 PM, Aaron Rosen wrote:
> Hi Phil, 
> 
> 
> On Thu, May 30, 2013 at 8:02 AM, Day, Phil <philip.day at hp.com
> <mailto:philip.day at hp.com>> wrote:
> 
>     Hi Folks,____
> 
>     __ __
> 
>     Currently the Nova SecGroup API extension doesn’t support the
>     Quantum egress rules (as these aren’t available in the native Nova
>     SecGroup implementation).     This can get quite confusing if there
>     are egress rules defined in Quantum that then don’t show up in Nova
>     (I know that’s partly the users problem for mixing their APIs)
> 
> 
> I agree. By default the 'default' security group in quantum allows all
> egress traffic same as nova so hopefully most people should not notice
> this (as you pointed out only if using both API's). 
>  
> 
>     – so I was wondering if as part of the V2 API work we could extend
>     the scope of the Nova SecGroup extension to include the concept of
>     egress rules, and then return a “Not Supported” error if someone
>     tries to create one on a system configured for Nova Networking.
> 
> 
> This seems easy enough to do but in my opinion but I don't think this
> would be moving us in the right direction. I see this more of a task of
> educating end users about the functionality differences. Security groups
> should be done in Quantum as part of networking. The proxy code was
> added to nova because the current nova api includes security groups
> attached to the instance. If egress filtering was added to nova,
>  horizon/python-novaclient would have to add support for this where it
> probably would have been easier to just switch over to quantum security
> groups that already implement this.  Lastly, the quantum security group
> api doesn't completely match up cleanly to the nova security group api
> (for example, quantum exposes ethertype). I would rather see efforts
> spent in moving away from proxing the security group info from nova to
> quantum to just talking to quantum. What do you think? 
> 
> That said if someone wants to add this extension great. :)  . 
> 
>     ____
> 
>     __ __
> 
>     What do people think, and how do ideas  like this get tagged against
>     the V3 work (new blueprint, add to an existing one, etc)
> 
> 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.

-- 
Russell Bryant