The similar problem has been discussed before.
There is no definitive answer, and currently seems we cannot simply disable
it since G version.
However, we can add some ALLOW rules to bypass the rules inside the
iptables chains.
Hope there be more flexibility to controller the security groups in the
future release.

On Tue, Sep 16, 2014 at 4:00 PM, Fawad Khaliq <> 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.
>    - 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]
> 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 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

Best wishes!
OpenStack-dev mailing list

Reply via email to