Set live_migration_wait_for_vif_plug when neutron uses ovs
Closes-issue: https://mirantis.jira.com/browse/PROD-23717
Change-Id: I02f29237dfd22c90121a4391a5b3b8687477c152
diff --git a/nova/files/queens/nova-compute.conf.Debian b/nova/files/queens/nova-compute.conf.Debian
index f7179e4..a18003b 100644
--- a/nova/files/queens/nova-compute.conf.Debian
+++ b/nova/files/queens/nova-compute.conf.Debian
@@ -4514,6 +4514,60 @@
# Minimum value: 1
#resource_provider_association_refresh = 300
+#
+# Determine if the source compute host should wait for a ``network-vif-plugged``
+# event from the (neutron) networking service before starting the actual
+# transfer
+# of the guest to the destination compute host.
+#
+# If you set this option the same on all of your compute hosts, which you should
+# do if you use the same networking backend universally, you do not have to
+# worry about this.
+#
+# Before starting the transfer of the guest, some setup occurs on the
+# destination
+# compute host, including plugging virtual interfaces. Depending on the
+# networking backend **on the destination host**, a ``network-vif-plugged``
+# event may be triggered and then received on the source compute host and the
+# source compute can wait for that event to ensure networking is set up on the
+# destination host before starting the guest transfer in the hypervisor.
+#
+# By default, this is False for two reasons:
+#
+# 1. Backward compatibility: deployments should test this out and ensure it
+# works
+# for them before enabling it.
+#
+# 2. The compute service cannot reliably determine which types of virtual
+# interfaces (``port.binding:vif_type``) will send ``network-vif-plugged``
+# events without an accompanying port ``binding:host_id`` change.
+# Open vSwitch and linuxbridge should be OK, but OpenDaylight is at least
+# one known backend that will not currently work in this case, see bug
+# https://launchpad.net/bugs/1755890 for more details.
+#
+# Possible values:
+#
+# * True: wait for ``network-vif-plugged`` events before starting guest transfer
+# * False: do not wait for ``network-vif-plugged`` events before starting guest
+# transfer (this is how things have always worked before this option
+# was introduced)
+#
+# Related options:
+#
+# * [DEFAULT]/vif_plugging_is_fatal: if ``live_migration_wait_for_vif_plug`` is
+# True and ``vif_plugging_timeout`` is greater than 0, and a timeout is
+# reached, the live migration process will fail with an error but the guest
+# transfer will not have started to the destination host
+# * [DEFAULT]/vif_plugging_timeout: if ``live_migration_wait_for_vif_plug`` is
+# True, this controls the amount of time to wait before timing out and either
+# failing if ``vif_plugging_is_fatal`` is True, or simply continuing with the
+# live migration
+# (boolean value)
+#live_migration_wait_for_vif_plug = false
+{%- if pillar.get('neutron', {}).get('compute', {}).get('backend', {}).get('mechanism', {}).get('ovs', {}).get('driver', '') == 'openvswitch' %}
+live_migration_wait_for_vif_plug = true
+{%- endif %}
+
[conductor]
#