yahoo-eng-team team mailing list archive

[Launchpad Bug Tracker <1245862@xxxxxxxxxxxxxxxxxx>]

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

** Changed in: neutron
       Status: Incomplete => Expired

-- 
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to neutron.
https://bugs.launchpad.net/bugs/1245862

Title:
  Duplicate iptables rule handling can be surprising

Status in OpenStack Neutron (virtual network service):
  Expired

Bug description:
  When helping someone debug a deployment we discovered a missing
  iptables rule that was required. The user appended the rule instead of
  inserting it which ended up placing it after a reject rule, rendering
  it moot. I asked them to insert it instead, so it looked something
  like

  USER-RULE  # inserted
  openstack-rule-0
  .
  .
  .
  openstack-rule-n-1
  openstack-rule-n -j REJECT 
  USER-RULE  # appended

  When IPTablesManager ran again, the rules looked like
  openstack-rule-0
  .
  .
  .
  openstack-rule-n-1
  openstack-rule-n -j REJECT 
  USER-RULE  # appended

  Oops!

  I had the user redirect the rules to a file and edit it manually to
  move the remaining rule to a "better" place.

  USER-RULE  # appended and moved
  openstack-rule-0
  .
  .
  .
  openstack-rule-n-1
  openstack-rule-n -j REJECT 

  ... and then the IPTablesManager left the rule alone and all was well
  with the world.

  I haven't debugged the IPTablesManager with a sample iptables set yet
  so I cannot state definitively if that is the root cause but I'm
  pointing the finger as the logic seems plausible.

  If it *is* the culprit. I wonder if it is possible to give precendence
  the first rule. Also it might be a good idea to add debug logging for
  dropping rules.

To manage notifications about this bug go to:
https://bugs.launchpad.net/neutron/+bug/1245862/+subscriptions