Set a flag to avoid ovs-agent remove all flows when it start

[Wei Wang]

See disscussion at http://lists.openstack.org/pipermail/openstack-dev/2014-October/049311.html.

In order to avoid cloud's network break, need to set a flag so that ovs-agent can get to know it doesn't need to remove flows for some reason.

[OpenStack Infra (hudson-openstack)]

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

[Wei Wang (damon-devops)]

We need more consideration, this is what I wrote in mail:

When I use the patch in experiment environment. Bad things happened:

1. Note that this is the old flows (Network node's br-tun, the previous
version is about icehouse):
"cookie=0x0, duration=238379.566s, table=1, n_packets=373521,
n_bytes=26981817, idle_age=0, hard_age=65534,
priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,21)
"cookie=0x0, duration=238379.575s, table=1, n_packets=30101,
n_bytes=3603857, idle_age=198, hard_age=65534,
priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)
"cookie=0x0, duration=238379.530s, table=20, n_packets=4957,
n_bytes=631543, idle_age=198, hard_age=65534, priority=0
actions=resubmit(,21)"
If the packet is a broadcast packet, we will resubmit it to table 20, and
table 20 will do nothing but resubmit to table 21.
the full sequence is:
from vxlan ports?: table 0 -> table 3 -> table 10 (learn flows and insert
to table 20)
from br-int?: table 0 -> table 1 -> (table 20) -> table 21

In the new version (about to juno), we discard table 1, use table 2 instead:
"cookie=0x0, duration=142084.354s, table=2, n_packets=175823,
n_bytes=12323286, idle_age=0, hard_age=65534,
priority=0,dl_dst=01:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,22)
"cookie=0x0, duration=142084.364s, table=2, n_packets=861601,
n_bytes=107499857, idle_age=0, hard_age=65534,
priority=0,dl_dst=00:00:00:00:00:00/01:00:00:00:00:00 actions=resubmit(,20)"
But if haven't remove all old flows, the table 1 will still exists, and it
will intercept packets, and try to submit packets to table 21 and 20, which
the correct tables are 22 and 20.
the full sequence is:
from vxlan ports?: table 0 -> table 4 -> table 10
from br-int?: table 0 -> table 2 -> (table 20, maybe output then!) -> table
22

Let's image we mix these up, because priority is 1 to table 0's flows, so
we can't make sure packets will trans to right flow, so some packets may
submit to table 21, this is quite beyond the pale!

2. What's more, let's imagine if we both use vxlan and vlan as provider:
since ovs-br's vlan is assigned as x, this will mod to y to br-int, but y
is assigned by ovs, not our config, so there may exist more than one mod
flow for vlan packet in ovs-br,
this will cause vlan_id falsify! And may cause network loop!

[Eugene Nikanorov (enikanorov)]

Please refer to https://bugs.launchpad.net/neutron/+bug/1383674 because it was filed earlier. Marking as duplicate.

[OpenStack Infra (hudson-openstack)]

Change abandoned by Kyle Mestery (<email address hidden>) on branch: master
Review: https://review.openstack.org/131791
Reason: This review is > 4 weeks without comment, and failed Jenkins the last time it was checked. We are abandoning this for now. Feel free to reactivate the review by pressing the restore button and leaving a 'recheck' comment to get fresh test results.