Hi Soren, Thanks for the insight, a few questions / comments:
> 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. Can see the advantage of this, but on an active system this can be quite an overhead compared to a periodic 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. I wonder if we're talking about the same driver - the code we're looking at is in the IptablesFirewallDriver in libvirt/firewall.py (which I think is moved up to virt/firewall.py in Essex). That seems to create a chain per Instance and do the update on a per instance basis, so I'm not quite sure I understand your point ? > 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. It may be that we're hitting a particular case - but we have a test system with 10's of VMs per host, on not many hosts, and some groups with 70+ VMs and a rule set that references the security group itself. So every VM in that group that gets refreshed (and there are many on each host) has to rebuild rules for each VM in the group. The impact of this overhead on every VM create and delete in un-related groups is killing the system - eps as the update code doesn't yield so other tasks on the compute node (such as the create itself are blocked). >Point 2 should be more palatable now that the simpler implementation has >proven itself. Could you clarify which simpler implementation your referring to - I've seen the NWFilterFirewall class and its associated comment block, but it wasn't clear to me under what circumstances it would be worth switching to this ? Thanks, Phil -----Original Message----- From: openstack-bounces+philip.day=hp....@lists.launchpad.net [mailto:openstack-bounces+philip.day=hp....@lists.launchpad.net] On Behalf Of Soren Hansen Sent: 23 February 2012 12:53 To: McNally, Dave (HP Cloud Services) Cc: openstack@lists.launchpad.net Subject: Re: [Openstack] Security Group Rule Refresh 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 _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
