we have to support keystone v3 for that.
https://projects.engineering.redhat.com/browse/RHV-756

WARN: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.2.z': '?'}', ]

For more info please contact: rhv-devops: Bug status wasn't changed from MODIFIED to ON_QA due to the following reason:

[Found non-acked flags: '{'rhevm-4.2.z': '?'}', ]

For more info please contact: rhv-devops

Moving back to post since there are unmerged referenced patches

Currently vm's connected using the openstack provider have their startup delayed by 15 seconds (they are paused for 15 seconds).
This is done to allow ovs to set up all networking before the vm goes up, to avoid problems with pxe booting.
Do we want to remove this feature for openstack ovn (https://gerrit.ovirt.org/#/c/94568/)?

(In reply to Marcin Mirecki from comment #6)
> Currently vm's connected using the openstack provider have their startup
> delayed by 15 seconds (they are paused for 15 seconds).
> This is done to allow ovs to set up all networking before the vm goes up, to
> avoid problems with pxe booting.
> Do we want to remove this feature for openstack ovn
> (https://gerrit.ovirt.org/#/c/94568/)?

Let QA decide if the implementation implements this feature.
We can dsicuss here if we want to have and test this feature.

(In reply to Dominik Holler from comment #7)
> (In reply to Marcin Mirecki from comment #6)
> > Currently vm's connected using the openstack provider have their startup
> > delayed by 15 seconds (they are paused for 15 seconds).

Bug 1314371 might be related.

> > This is done to allow ovs to set up all networking before the vm goes up, to
> > avoid problems with pxe booting.
> > Do we want to remove this feature for openstack ovn
> > (https://gerrit.ovirt.org/#/c/94568/)?
> 
> Let QA decide if the implementation implements this feature.
> We can dsicuss here if we want to have and test this feature.

A question for certification: Which ovn-controller is installed on the host? The one distributed by RHV or OpenStack? If the one from RHV is used, is it compatible the ovn-central from OpenStack?

Referenced in vdsm v4.30.3 despite this is an ovirt-engine bug

Verified on vdsm-4.30.8-2.el7ev.x86_64, vdsm-hook-openstacknet-4.30.8-2.el7ev.noarch and rhvm-4.3.0.4-0.1.el7.noarch with - 

Red Hat OpenStack Platform release 14.0.0 RC (Rocky)

openvswitch2.10-ovn-common-2.10.0-28.el7fdp.x86_64
rhv-openvswitch-ovn-central-2.10-3.el7ev.noarch
ovirt-provider-ovn-1.2.19-1.el7ev.noarch
puppet-ovn-13.3.1-0.20181013120724.38e2e33.el7ost.noarch
openvswitch2.10-ovn-central-2.10.0-28.el7fdp.x86_64
ovirt-provider-ovn-driver-1.2.19-1.el7ev.noarch
rhosp-openvswitch-ovn-host-2.10-0.1.el7ost.noarch
rhosp-openvswitch-ovn-common-2.10-0.1.el7ost.noarch
openvswitch2.10-ovn-host-2.10.0-28.el7fdp.1.x86_64

f0507a90c50e        x.x.x.x:8787/rhosp14/openstack-ovn-controller:2019-01-16.1            "kolla_start"            3 days ago          Up 3 days                                 ovn_controller
828abe215790        x.x.x.x:8787/rhosp14/openstack-neutron-server-ovn:2019-01-16.1        "kolla_start"            3 days ago          Up 3 days (healthy)                       neutron_api
839686faa60e        x.x.x.x:8787/rhosp14/openstack-nova-novncproxy:2019-01-16.1           "kolla_start"            3 days ago          Up 3 days (healthy)                       nova_vnc_proxy
0b88c6f0436b        x.x.x.x:8787/rhosp14/openstack-ovn-northd:pcmklatest                  "/bin/bash /usr/lo..."   3 days ago          Up 3 days                                 ovn-dbs-bundle-docker-0

Certified with the only exception that the port's state is sometimes DOWN after migration(from time to time), but everything is working as expected and VMs can communicate after migrations. See BZ 1655906

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHEA-2019:1085