1. This can already be done using existing APIs (as noted) client-side if monitoring the live migration and it times out for whatever you consider a reasonable timeout at the time.
There's another thing to point out here, which is that this is also already doable by adjusting (rightly libvirt-specific) config tunables on a compute node that is being evacuated. Those could be hot-reloadable, meaning they could be changed without restarting the compute service when the evac process begins. It doesn't let you control it per-instance, granted, but there *is* a server-side solution to this based on existing stuff.
2. The libvirt driver is the only one that currently supports abort and force-complete.
For #1, while valid as a workaround, is less than ideal since it would mean having to orchestrate that into any tooling that needs that kind of workaround, be that OSC, openstacksdk, python-novaclient, gophercloud, etc. I think it would be relatively simple to pass those parameters through with the live migration request down to nova-compute and have the parameters override the config options and then it's natively supported in the API.
For #2, while also true, I think is not a great reason *not* to support per-instance timeouts/actions in the API when we already have existing APIs that do the same thing and have the same backend compute driver limitations. To ease this, I think we can sort out two things:
a) Can other virt drivers that support live migration (xenapi, hyperv, vmware in tree, and powervm out of tree) also support abort and force-complete actions? John Garbutt at least thought it should be possible for xenapi at the Stein PTG. I don't know about the others - driver maintainers please speak up here. The next challenge would be getting driver maintainers to actually add that feature parity, but that need not be a priority for Stein as long as we know it's possible to add the support eventually.
I think that we asked Eric and he said that powervm would/could not support such a thing because they hand the process off to the hypevisor and don't pay attention to what happens after that (and/or can't cancel it). I know John said he thought it would be doable for xenapi, but even if it is, I'm not expecting it will happen. I'd definitely like to hear from the others.
b) There are pre-live migration checks that happen on the source compute before we initiate the actual guest transfer. If a user (admin) specified these new parameters and the driver does not support them, we could fail the live migration early. This wouldn't change the instance status but the migration would fail and an instance action event would be recorded to explain why it didn't work, and then the admin can retry without those parameters. This would shield us from exposing something in the API that could give a false sense of functionality when the backend doesn't support it.
This is better than nothing, granted. What I'm concerned about is not that $driver never supports these, but rather that $driver shows up later and wants *different* parameters. Or even that libvirt/kvm migration changes in such a way that these no longer make sense even for it. We already have an example this in-tree today, where the recently-added libvirt post-copy mode makes the 'abort' option invalid.
Given all of this, are these reasonable compromises to continue trying to drive this feature forward, and more importantly, are other operators looking to see this functionality added to nova? Huawei public cloud operators want it because they routinely are doing live migrations as part of maintenance activities and want to be able to control these values per-instance. I assume there are other deployments that would like the same.
I don't need to hold this up if everyone else is on board, but I don't really want to +2 it. I'll commit to not -1ing it if it specifically confirms support before starting a migration that won't honor the requested limits. --Dan