Comment 7 for bug 1729566

Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix merged to kolla-ansible (master)

Reviewed: https://review.opendev.org/715494
Committed: https://git.openstack.org/cgit/openstack/kolla-ansible/commit/?id=628c27ce9e693902c5cabedc7f254f2a1229a195
Submitter: Zuul
Branch: master

commit 628c27ce9e693902c5cabedc7f254f2a1229a195
Author: John Garbutt <email address hidden>
Date: Fri Mar 27 17:37:51 2020 +0000

    Fix live migration to use migration int. address

    In kolla ansible we typically configure services to communicate via IP
    addresses rather than hostnames. One accidental exception to this was
    live migration, which used the hostname of the destination even when
    not required (i.e. TLS not being used for libvirt).

    To make such hostnames work, k-a adds entries to /etc/hosts in the
    bootstrap-servers command. Alternatively users may provide DNS.

    One problem with using /etc/hosts is that, if a new compute host is
    added to the cloud, or an IP address is changed, that will not be
    reflected in the /etc/hosts file of other hosts. This would cause live
    migration to the new host from an old host to fail, as the name cannot
    be resolved.

    The workaround for this was to update the /etc/hosts file (perhaps via
    bootstrap-servers) on all hosts after adding new compute hosts. Then the
    nova_libvirt container had to be restarted to pick up the change.

    Similarly, if user has overridden the migration_interface, the used
    hostname could point to a wrong address on which libvirt would not
    listen.

    This change adds the live_migration_inbound_addr option to nova.conf. If
    TLS is not in use for libvirt, this will be set to the IP address of the
    host on the migration network. If TLS is enabled for libvirt,
    live_migration_inbound_addr will be set to migration_hostname, since
    certificates will typically reference the hostname rather than the
    host's IP. With libvirt TLS enabled, DNS is recommended to avoid the
    /etc/hosts issue which is likely the case in production deployments.

    Change-Id: I0201b46a9fbab21433a9f53685131aeb461543a8
    Closes-Bug: #1729566