2012/2/22 McNally, Dave (HP Cloud Services) <dave.mcna...@hp.com>: > 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?
I forget the exact history here (i.e. why some of the method calls include it and why some don't), but there are three reasons I decided to do a full refresh: 1 deal with the situation where a refresh call to one of the compute nodes got lost. If that happened, at least it would all get sorted out on the next refresh. 2 the routine that turned the rules from the database into iptables rules was complex enough as it was. Making it remove only rules for a single security group or a single instance or whatever would make it even worse. 3 The difference in terms of efficiency is miniscule. iptables replaces full tables at a time anyway, and while the relative amount of data needed to be fetched from the database might be much larger than with a more selective refresh, the absolute amount of data is still pretty small. Point 1 could be addressed now by a periodical refresh of the rules, if one was so inclined. Point 2 should be more palatable now that the simpler implementation has proven itself. Point 3 might be less true now. In the beginning, there were separate chains for each security group, now it's just one big list, IIRC. That may change things. -- Soren Hansen | http://linux2go.dk/ Senior Software Engineer | http://www.cisco.com/ Ubuntu Developer | http://www.ubuntu.com/ OpenStack Developer | http://www.openstack.org/ _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
