Agree! +1 On Thu, Sep 18, 2014 at 1:47 PM, Lingxian Kong <[email protected]> wrote:
> 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 <[email protected]>: > > 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" <[email protected]> 写道： > > > > Hi, > > > > Inline: > > > > On Tue, Sep 16, 2014 at 1:00 AM, Fawad Khaliq <[email protected]> > 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 > >> [email protected] > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > >> > > > > > > > > > > _______________________________________________ > > OpenStack-dev mailing list > > [email protected] > > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > > > > -- > Regards! > ----------------------------------- > Lingxian Kong > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > -- Best wishes! Baohua
_______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
