Add a live migration test without peer-to-peer connection

[tpressure]

No description provided.

[phip1611]

Can you please elaborate a little about the missing why part?

[hertrste]

Can you please elaborate a little about the missing why part?

We have broken the migration when not using the --p2p flag. This broke during the non-blocking virsh calls during a migration feature development.

As OpenStack Nova always uses the --p2p flag, we might also just enforce the P2P migration and throw an error otherwise. This test is able to show the current regression. I think we have to decide how to go forward now.

I would consider this a draft at this point

[phip1611]

Would it make sense to refactor our “static” tests—or at least parts of them—into a generated, matrix-style set of tests, e.g.:

{p2p,direct}x{no_plug,device_hotplug}x{libvirt-daemon-restart,norestart}x{tcp-serial,pty-serial}?

I would consider this a draft at this point

we can briefly discuss this in today's sync

[hertrste]

Would it make sense to refactor our "static" tests or at least parts of that to a generated matrix-style list of tests? {p2p,direct}x{no_plug,device_hotplug}x{libvirt-daemon-restart,norestart}x{tcp-serial,pty-serial}?

I think that makes sense to some degree.

But for this case, I think we might just say we only support p2p migration and drop the "legacy" migration support. Because it does not really makes sense to support a feature we do not use in the end. Further, I also plan to only support P2P migration when upstreaming the feature (not checked back if upstream is okay with that, but it is the plan for now).

[phip1611]

For the record: Must be rebased onto #41

[phip1611]

Would it make sense to refactor our "static" tests or at least parts of that to a generated matrix-style list of tests? {p2p,direct}x{no_plug,device_hotplug}x{libvirt-daemon-restart,norestart}x{tcp-serial,pty-serial}?

I think that makes sense to some degree.

But for this case, I think we might just say we only support p2p migration and drop the "legacy" migration support. Because it does not really makes sense to support a feature we do not use in the end. Further, I also plan to only support P2P migration when upstreaming the feature (not checked back if upstream is okay with that, but it is the plan for now).

pytest has built-in support for this. Example pseudo code generated by chatgpt:

import pytest

# Define all dimensions of your test matrix
p2p_modes = ["p2p", "direct"]
plug_modes = ["no_plug", "device_hotplug"]
daemon_modes = ["libvirt-daemon-restart", "norestart"]
serial_modes = ["tcp-serial", "pty-serial"]

# Generate all combinations
from itertools import product
test_matrix = list(product(p2p_modes, plug_modes, daemon_modes, serial_modes))

@pytest.mark.parametrize("p2p_mode,plug_mode,daemon_mode,serial_mode", test_matrix)
def test_libvirt_matrix(p2p_mode, plug_mode, daemon_mode, serial_mode):
    """
    Matrix-style libvirt test.

    Each parameter combination is automatically run as a separate test case.
    """
    # Example debug print
    print(f"Running test with: {p2p_mode=}, {plug_mode=}, {daemon_mode=}, {serial_mode=}")

[tpressure]

pytest has built-in support for this. Example pseudo code generated by chatgpt:

This is really nice. When we refactor the tests some day, we definitively do it like this.