ovs_lib: apply order for deferred flows problematic for ovs-firewall-driver

[Vishal Thapar]

ovs_lib.py provides defer_apply_on/off methods to bulk apply flow changes on a bridge. Currently the order in which flows get applied is add, mod, del. This causes problems for ovs-firewall-driver. update_port_filter() deletes all existing flows on a port and then adds new flows. But because of fixed order of deferred flows the addition of new flows is done first and then cleanup deleting all flows. This results in a scenario where update_port_filter ends up wiping out all flows.

This is a big issue for ovs-firewall-driver. There should be a means to tweak the order in which flows will be applied when turning deferred_apply_on.

[Cedric Brandily (cbrandily)]

A rework[1] on defer_apply_on/off is in progress, perhaps it could solve your trouble ?

[1] https://review.openstack.org/77578

[Vishal Thapar (vthapar)]

cbrandily: Oh yes, looks like it would. How can I get in touch with you to understand the changes and how to use deferred flows? It looks like you're not 'fixing' deferred_apply_on/off() and I'd like to understand the implementation better.

[Cedric Brandily (cbrandily)]

We replace it with a deferred OVSBridge which ensures that during apply you only apply your flows (it is not the case if defer_apply_on/off).

Cedric
zzelle@IRC

[Cedric Brandily (cbrandily)]

https://review.openstack.org/77578 has been merged, i hope it could help

[Sudhakar Gariganti (sudhakar-gariganti)]

As cbrandily also confirmed, this is no longer a defect considering the new defer_apply approach.
Close the bug?