openstack team mailing list archive

["Day, Phil" <philip.day@xxxxxx>]

OK - I'll put a description into lanchpad along with our notes on how we're proposing to fix this on our Diablo branch (as there is a performance related change in here as well)

As with the previous performance change it will take us some time to get an Essex compatible fix - but if I provide all the details perhaps someone else can pick this up in parallel.

Phil

From: openstack-bounces+philip.day=hp.com@xxxxxxxxxxxxxxxxxxx [mailto:openstack-bounces+philip.day=hp.com@xxxxxxxxxxxxxxxxxxx] On Behalf Of Vishvananda Ishaya
Sent: 22 February 2012 22:00
To: McNally, Dave (HP Cloud Services)
Cc: openstack@xxxxxxxxxxxxxxxxxxx
Subject: Re: [Openstack] Security Group Rule Refresh

Maybe soren has a comment on this, but as far as I can tell it looks like a bug.  It seems getting a list of instances that are in that group and refreshing those would be the right approach.

Vish

On Feb 22, 2012, at 9:13 AM, McNally, Dave (HP Cloud Services) wrote:


Hi all,

Currently I'm trying to track how a refresh of the security groups is handled (upon creation or deletion of a vm). Following through the code I get to 'do_refresh_security_group_rules' in libvirt/firewall.py. Up to this point the security group in question has been carried through however it seems to be discarded here and rather than filtering the instances to refresh the rules for based on this group it looks to me like all instances on the current host are iterated through and then there is an attempt to update the rules for all these instances.

Is this full refresh necessary/intentional? If so can anyone tell me why it's required?

Thanks,

Dave
_______________________________________________
Mailing list: https://launchpad.net/~openstack
Post to     : openstack@xxxxxxxxxxxxxxxxxxx<mailto:openstack@xxxxxxxxxxxxxxxxxxx>
Unsubscribe : https://launchpad.net/~openstack
More help   : https://help.launchpad.net/ListHelp