Hi, Inline:
On Tue, Sep 16, 2014 at 1:00 AM, Fawad Khaliq <fa...@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@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >
_______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
