[openstack-dev] [neutron][security-groups] Neutron default security groups

Lingxian Kong anlin.kong at gmail.com
Thu Sep 18 05:47:34 UTC 2014


Hi, shihanzhang:

Thanks for bringing this up, again.

As I said before, this blueprint will solve the problems that the
'hard-coded' rules related to the default security group we are
suffering from, which I do think will give Fawad an anser. So, I
really hope that we can particapate all together to make this happen
in Kilo.

2014-09-17 10:11 GMT+08:00 shihanzhang <ayshihanzhang at 126.com>:
> As I know there is no a way to disable default security groups, but I think
> this BP can solve this problem:
> https://blueprints.launchpad.net/neutron/+spec/default-rules-for-default-security-group
>
>
> 在 2014-09-17 07:44:42,"Aaron Rosen" <aaronorosen at gmail.com> 写道:
>
> Hi,
>
> Inline:
>
> On Tue, Sep 16, 2014 at 1:00 AM, Fawad Khaliq <fawad at plumgrid.com> wrote:
>>
>> Folks,
>>
>> I have had discussions with some folks individually about this but I would
>> like bring this to a broader audience.
>>
>> I have been playing with security groups and I see the notion of 'default'
>> security group seems to create some nuisance/issues.
>>
>> There are list of things I have noticed so far:
>>
>> Tenant for OpenStack services (normally named service/services) also ends
>> up having default security group.
>> Port create operation ends up ensuring default security groups for all the
>> tenants as this completely seems out of the context of the tenant the port
>> operation takes place. (bug?)
>> Race conditions where if system is stressed and Neutron tries to ensure
>> the first default security group and in parallel another call comes, Neutron
>> ends up trying to create multiple default security groups as the checks for
>> duplicate groups are invalidated as soon as the call make past a certain
>> point in code.
>
> Right this is a bug. We should catch this foreign key constraint exception
> here and pass as the default security group was already created. We do
> something similar here when ports are created as there is a similar race for
> ip_allocation.
>>
>>
>> API performance where orchestration chooses to spawn 1000 tenants and we
>> see unnecessary overhead
>>
>> For plugins that use RESTful proxy backends require the backend systems to
>> be up at the time neutron starts. [Minor, but affects some packaging
>> solutions]
>
>
> This is probably always a requirement for neutron to work so I don't think
> it's related.
>>
>>
>> To summarize, is there a way to disable default security groups? Expected
>> answer is no; can we introduce a way to disable it? If that does not make
>> sense, should we go ahead and fix the issues around it?
>
>
> I think we should fix these bugs you pointed out.
>>
>>
>> I am sure some of you must have seen some of these issues and solved them
>> already. Please do share how do tackle these issues?
>>
>> Thanks,
>> Fawad Khaliq
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev at lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Regards!
-----------------------------------
Lingxian Kong



More information about the OpenStack-dev mailing list