iptables manager doesn't properly handle duplicate non-wrapped chains

Bug #1311904 reported by Aaron Knister
16
This bug affects 3 people
Affects Status Importance Assigned to Milestone
neutron
Expired
Undecided
Unassigned

Bug Description

The iptables manager can fail to load iptables rules if a chain to be created already exists. The solution seems to be to decrement rule_index. This seems to cause vif plugging to fail.

Changed in neutron:
assignee: nobody → Aaron Knister (aaron-knister)
description: updated
Revision history for this message
Openstack Gerrit (openstack-gerrit) wrote : Fix proposed to neutron (master)

Fix proposed to branch: master
Review: https://review.openstack.org/89952

Changed in neutron:
status: New → In Progress
Revision history for this message
Openstack Gerrit (openstack-gerrit) wrote : Fix proposed to neutron (stable/havana)

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/89953

Revision history for this message
Openstack Gerrit (openstack-gerrit) wrote :

Fix proposed to branch: stable/havana
Review: https://review.openstack.org/89956

Revision history for this message
Openstack Gerrit (openstack-gerrit) wrote : Fix proposed to neutron (stable/icehouse)

Fix proposed to branch: stable/icehouse
Review: https://review.openstack.org/89957

Revision history for this message
Brian Haley (brian-haley) wrote : Re: iptables manager doesn't decrement rule_index upon duplicate chain

Can you give an example of this failure? I have an out-of-tree test that can pass duplicate chains and I don't see the failure. I'm not saying there isn't something broken though...

Revision history for this message
Nachi Ueno (nati-ueno) wrote :

yes. could you share how to reproduce this?

Changed in neutron:
status: In Progress → Incomplete
Revision history for this message
Aaron Knister (aaron-knister) wrote :

Sorry for the very long delay here. I've reproduced this with a minimal set of firewall rules that I've attached below. The neutron ovs agent will consistently blow up if it starts up after these rules have been applied.

Changed in neutron:
status: Incomplete → In Progress
Revision history for this message
Aaron Knister (aaron-knister) wrote :

I also re-based the patch just now

Revision history for this message
Aaron Knister (aaron-knister) wrote :

I snuck a debugging statement in the code and grabbed the list of rules just before they were applied. I'm attaching logs of the same step with and without the patch.

Revision history for this message
Aaron Knister (aaron-knister) wrote :
Revision history for this message
Aaron Knister (aaron-knister) wrote :
Revision history for this message
Aaron Knister (aaron-knister) wrote :

After creating the unit test, it looks like this specifically happens with duplicate rules (duplicate relative to the rules currently loaded in iptables) that are not wrapped (e.g. table.add_rule('myrule' ,wrap=False)).

summary: - iptables manager doesn't decrement rule_index upon duplicate chain
+ iptables manager doesn't properly handle duplicate non-wrapped chains
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (stable/havana)

Change abandoned by Aaron Knister (<email address hidden>) on branch: stable/havana
Review: https://review.openstack.org/89956
Reason: Abandoning until the merge into master is complete.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (stable/icehouse)

Change abandoned by Aaron Knister (<email address hidden>) on branch: stable/icehouse
Review: https://review.openstack.org/89957
Reason: Abandoning until change is merged into master.

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on neutron (master)

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/89952
Reason: This change is old enough and hasn't seen any updates since July 30, 2014. Abandoning it, please revive it if you plan to work on it again.

Revision history for this message
Armando Migliaccio (armando-migliaccio) wrote :

This bug is > 172 days without activity. We are unsetting assignee and milestone and setting status to Incomplete in order to allow its expiry in 60 days.

If the bug is still valid, then update the bug status.

Changed in neutron:
assignee: Aaron Knister (aaron-knister) → nobody
status: In Progress → Incomplete
Revision history for this message
Launchpad Janitor (janitor) wrote :

[Expired for neutron because there has been no activity for 60 days.]

Changed in neutron:
status: Incomplete → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

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