Firewall rules are not updated if you restart nova-compute

Bug #1043886 reported by Jimmy Bergman
8
This bug affects 1 person
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Fix Released
Medium
Unassigned

Bug Description

IptablesFirewallDriver from nova/virt/firewall.py keeps a list of instances in self.instances.

When nova-compute starts this is empty. It is not loaded at start in some way, instead
it is filled using the prepare_instance_filter method.

This method is called from the virt drivers in a few scenarios that are different on
libvirt and xenapi (these are the ones I checked).

On xenapi it only happens during spawn, on libvirt it also happens during hard reboot.

This means that if you have some running instances using some security group, and then for
some reason restart the nova-compute service - updates to the security group (i.e.
adding/removing some rule) will not be propagated to iptables correctly. On libvirt
you can "fix" this by rebooting an instance hard. On xenapi you can't fix it.

I added an ugly hack to make xenapi work like I want it to (but I can see that it is
not fit for inclusion). I would be happy to fix this in some less ugly way if someone
gave me a helpful hint of what the core devs would consider be a good way to solve it.

To me perhaps the reasonable thing would be for IptablesFirewallDriver to treat
self.instances as a cache and if some instance is not there, then check if it is running
and if so - fetch the network_info + do prepare_instance_filter.

Anyway, here is my ugly hack patch, perhaps it helps someone or gives more insight into
what I mean :-):

--- /home/atomia/jma_backup/nova/virt/xenapi/vmops.py 2012-06-12 15:04:56.000000000 +0200
+++ /usr/lib/python2.7/dist-packages/nova/virt/xenapi/vmops.py 2012-08-30 16:37:58.226715150 +0200
@@ -32,6 +32,7 @@

 from nova.compute import api as compute
 from nova.compute import power_state
+from nova.compute import utils as compute_utils
 from nova import context as nova_context
 from nova import db
 from nova import exception
@@ -1749,6 +1750,16 @@

     def refresh_security_group_rules(self, security_group_id):
         """ recreates security group rules for every instance """
+ LOG.debug("JMA: refresh_security_group_rules for " + str(security_group_id) + ", the firewall driver is of type " + self.firewall_driver.__class__.__name__)
+
+ import nova.network
+ nw_api = nova.network.API()
+ context = nova_context.get_admin_context()
+ security_group = db.security_group_get(context, security_group_id)
+ for instance in security_group['instances']:
+ nw_info = compute_utils.legacy_network_info(nw_api.get_instance_nw_info(context, instance))
+ self.firewall_driver.prepare_instance_filter(instance, nw_info)
+
         self.firewall_driver.refresh_security_group_rules(security_group_id)

     def refresh_security_group_members(self, security_group_id):

Revision history for this message
Vish Ishaya (vishvananda) wrote :

Seems like iptables rules should be refreshed on restart of nova-compute.

Changed in nova:
status: New → Triaged
importance: Undecided → Medium
Revision history for this message
Vish Ishaya (vishvananda) wrote :

FYI you can also fix it by adding or removing a rule from the group, which will trigger a refresh.

Revision history for this message
Jimmy Bergman (jimmy-sigint) wrote :

Actually this didn't happen at least on the xenapi driver (essex).

I was also expecting it to happen since it calls self.driver.refresh_provider_fw_rules(), but that wouldn't
do anything since self.instances in the IptablesFirewallDriver from nova/virt/firewall.py was empty.

Possibly HEAD is different.

Changed in nova:
status: Triaged → Fix Released
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.