Comment 1 for bug 1691769

Revision history for this message
Matt Riedemann (mriedem) wrote :

Here is the state of our jobs that run live migration today:

1. gate-tempest-dsvm-multinode-live-migration-ubuntu-xenial

This is the multinode non-upgrade same-level computes live-migration job. This does not run with live_migrate_back_and_forth enabled. It tests local disk block migration and ceph-backed local disk shared storage migration (no volumes).

2. gate-tempest-dsvm-neutron-multinode-full-ubuntu-xenial-nv

Same as #1 except no ceph.

3. gate-grenade-dsvm-neutron-multinode-ubuntu-xenial

This does not test live migration since it only runs smoke tests and the live migration tests aren't listed as smoke tests.

4. gate-grenade-dsvm-neutron-multinode-live-migration-nv

Multinode mixed-level compute job which tests live migration for local disk live block migration and local disk shared storage on ceph live migration, no volume-backed live migration. It also runs with live_migrate_back_and_forth=True which means it live migrations between mixed level computes, so pike->ocata->pike (well, it would after anyway).


So right now we have no live migration coverage for ceph, and we have no live migration coverage for mixed-level computes since gate-grenade-dsvm-neutron-multinode-live-migration-nv isn't working.

Our options are:

a) Make the job work with both systemd and screen, by either re-writing it to re-use functions available in devstack, or bake in our own logic for how to handle restarts depending on how the job is configured (I don't have a good sense for which is harder to do).

b) Do nothing - basically disable the job from running on master (pike) and then re-enable it for Queens when n-1 would be pike and would use systemd by default. This would mean we'd have no ceph-backed live migration or mixed-compute live migration for all of Pike (and when it's stable/pike).