[openstack-dev] Make Secgroup extension fully compatible with Quantum as part of V3

Aaron Rosen arosen at nicira.com
Thu May 30 17:35:31 UTC 2013


Hi Phil,


On Thu, May 30, 2013 at 8:02 AM, Day, Phil <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.


> ****
>
> ** **
>
> Phil
>
Best,

Aaron


> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> 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/20130530/ce4dd0cf/attachment.html>


More information about the OpenStack-dev mailing list