No config to permit live-migration auto converge and post copy modes

[Niels van Adrichem]

The nova-compute charm does not yet have the configuration options to permit auto-converge and post-copy mode as described in https://docs.openstack.org/nova/queens/admin/live-migration-usage.html#addressing-migration-timeouts .

I already made and submitted a patch for review to Gerrit at https://review.openstack.org/#/c/613079/ and it passes Zuul check and Canonical CI tests. I'll amend it with the appropriate reference to this bug.

I decided to only include the configuration parameters to the nova.conf template when live-migration is actually enabled, since the parameters don't make sense without live-migration enabled.

[James Page (james-page)]

https://review.openstack.org/#/c/613079

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/613079
Committed: https://git.openstack.org/cgit/openstack/charm-nova-compute/commit/?id=1fa2a8023cd4b1acee891a09311f4fd1b803e85d
Submitter: Zuul
Branch: master

commit 1fa2a8023cd4b1acee891a09311f4fd1b803e85d
Author: Niels van Adrichem <email address hidden>
Date: Wed Oct 24 14:07:33 2018 +0000

    Enable support for auto-converge and post-copy

    Implement missing configuration options and context to support
    configuration of:

      live_migration_permit_auto_converge
      live_migration_permit_post_copy

    in nova.conf. The configuration parameters are only added to the
    nova.conf template when live-migration is actually enabled, since they
    have no purpose without live-migration enabled. The options are added to
    version Newton and upwards as that is the Nova version since they were
    first supported.

    Change-Id: I1bb3cee4ac532d0867b4297c742707668566a527
    Closes-Bug: #1799916

[Edward Hope-Morley (hopem)]

We just hit an issue where live migration of busy VMs was taking a very long time to complete. We checked all the usual suspects that could cause it and did not find anything so ended up trying enabling these opts and live migrations have significantly sped up. I know this is a feature addition and therefore not typically eligible for backport but since it is entirely contained and does not change existing behaviour (without modifying the config) I would like to propose it for backport since we very much need this deployed asap.

[OpenStack Infra (hudson-openstack)]

Fix proposed to branch: stable/18.11
Review: https://review.openstack.org/640060

[Drew Freiberger (afreiberger)]

Can we please ensure this gets updated for the Rocky nova.conf template as well?

Possible that this was developed around the same time as rocky templates and we just hit a race in development efforts.

[Edward Hope-Morley (hopem)]

On it...

[Edward Hope-Morley (hopem)]

https://review.openstack.org/640109

[OpenStack Infra (hudson-openstack)]

Related fix proposed to branch: master
Review: https://review.openstack.org/640109

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/640109
Committed: https://git.openstack.org/cgit/openstack/charm-nova-compute/commit/?id=a37c470e1fe1a51c4e0935ffe10ac1bd7f8810b7
Submitter: Zuul
Branch: master

commit a37c470e1fe1a51c4e0935ffe10ac1bd7f8810b7
Author: Edward Hope-Morley <email address hidden>
Date: Thu Feb 28 17:04:47 2019 +0000

    Add config missing in rocky template

    These nova.conf config were added while rocky was being added and
    so didnt make it into the rocky nova.conf (since the template didnt
    exist when the patches were started).

    Change-Id: Ie4d3ba515cb0a6f9f7fa198a9ac1c05c4c2c233a
    Related-Bug: #1804169
    Related-Bug: #1799916

[Drew Freiberger (afreiberger)]

Subscribed Field-High because we need the stable/18.11 backport of these options to enable live-migration for live customer workloads on a very busy cloud.

Please Review this backport for Merge: https://review.openstack.org/640060

[Chris MacNaughton (chris.macnaughton)]

@Ed & @Drew,

As this is new feature work, rather than bugfix, I'd be much more amenable to creating a feature branch with this cherry-picked onto stable and made available, rather than backporting the new feature, until the next charms release (in around 6 weeks).

I will create a revision of this charm with stable/18.11 + the proposed backport and publish that in my namespace for validation. Further discussion of backporting is possible but is a somewhat more difficult discussion as this change does include new feature work and so is explicitly excluded in our backporting policy.

[Chris MacNaughton (chris.macnaughton)]

https://jujucharms.com/u/chris.macnaughton/nova-compute/0 is a snapshot taken from the backport review, pending further discussion of backporting a new feature.

[OpenStack Infra (hudson-openstack)]

Reviewed: https://review.openstack.org/640060
Committed: https://git.openstack.org/cgit/openstack/charm-nova-compute/commit/?id=0043d38223dfec0a86abdf0a8968598751511a1e
Submitter: Zuul
Branch: stable/18.11

commit 0043d38223dfec0a86abdf0a8968598751511a1e
Author: Niels van Adrichem <email address hidden>
Date: Wed Oct 24 14:07:33 2018 +0000

    Enable support for auto-converge and post-copy

    Implement missing configuration options and context to support
    configuration of:

      live_migration_permit_auto_converge
      live_migration_permit_post_copy

    in nova.conf. The configuration parameters are only added to the
    nova.conf template when live-migration is actually enabled, since they
    have no purpose without live-migration enabled. The options are added to
    version Newton and upwards as that is the Nova version since they were
    first supported.

    Change-Id: I1bb3cee4ac532d0867b4297c742707668566a527
    Closes-Bug: #1799916
    (cherry picked from commit 1fa2a8023cd4b1acee891a09311f4fd1b803e85d)

[Edward Hope-Morley (hopem)]

@chris.macnaughton I understand your reticence to backport features as that is understandably the normal policy. The reason I pushed for this backport is (a) it is proving very effective at resolving the problem of live migrating busy workloads in the field (without it they can take an inordinate amount of time) and (b) it does not change default behaviour at all i.e. anybody uptrading to a charm with this patch will so no difference in the way their services operate since the defaults are the same.