My last comment was perhaps a bit longer than it needed to be.
The tl;dr version is that after ovsdb-server is restarted, n-o-a starts a new ovsdb-client (in ekarlson's case the old client is not killed, but a new one does get started). The new ovsdb-client doesn't re-add the flows, so no traffic flows.
When n-o-a is restarted, the flows are recreated.
The brute-force workaround is to restart neutron-openvswitch-agent each time ovsdb-server is restarted; a better solution might be for the new ovsdb-client process be a trigger for checking and re-adding the required flows.
My last comment was perhaps a bit longer than it needed to be.
The tl;dr version is that after ovsdb-server is restarted, n-o-a starts a new ovsdb-client (in ekarlson's case the old client is not killed, but a new one does get started). The new ovsdb-client doesn't re-add the flows, so no traffic flows.
When n-o-a is restarted, the flows are recreated.
The brute-force workaround is to restart neutron- openvswitch- agent each time ovsdb-server is restarted; a better solution might be for the new ovsdb-client process be a trigger for checking and re-adding the required flows.