Re: [PATCH] migration: do not exit on incoming failure

[Peter Xu]

On Thu, Apr 18, 2024 at 06:47:31PM +0300, Vladimir Sementsov-Ogievskiy wrote:
> On 18.04.24 18:43, Daniel P. Berrangé wrote:
> > On Thu, Apr 18, 2024 at 06:40:38PM +0300, Vladimir Sementsov-Ogievskiy 
> > wrote:
> > > On 18.04.24 17:37, Daniel P. Berrangé wrote:
> > > > On Thu, Apr 18, 2024 at 01:13:29AM +0300, Vladimir Sementsov-Ogievskiy 
> > > > wrote:
> > > > > We do set MIGRATION_FAILED state, but don't give a chance to
> > > > > orchestrator to query migration state and get the error.
> > > > > 
> > > > > Let's report an error through QAPI like we do on outgoing migration.
> > > > > 
> > > > > migration-test is updated correspondingly.
> > > > > 
> > > > > Signed-off-by: Vladimir Sementsov-Ogievskiy 
> > > > > <vsementsov@yandex-team.ru>
> > > > > ---
> > > > > 
> > > > > Doubt: is exiting on failure a contract? Will this commit break
> > > > > something in Libvirt? Finally, could we just change the logic, or I 
> > > > > need
> > > > > and additional migration-parameter for new behavior?
> > > > 
> > > > There's a decent risk that this could break apps, whether
> > > > libvirt or something else, especially if the app is just
> > > > launching QEMU with '-incoming URI', rather than using
> > > > '-incoming defer' and then explicitly using QMP to start the
> > > > incoming migration.
> > > > 
> > > > I'd say that with '-incoming defer' we should *not* exit on
> > > > migration error, because that arg implies the app explicitly
> > > > wants to be using QMP to control migration.
> > > > 
> > > > With the legacy '-incoming URI' it is probably best to keep
> > > > exit on error, as that's comparatively more likely to be used
> > > > in adhoc scenarios where the app/user is ignoring QMP on the
> > > > dst side.
> > > > 
> > > > None the less, I think we need to check how libvirt behaves
> > > > with this patch to be sure of no surprises.
> > > > 
> > > 
> > > Sounds reasonable, thanks! I'll rework it to behave the new
> > > way only with "-incoming defer", and check how libvirt behave with it.
> > 
> > If there are problems and/or we want to be super safe wrt
> > backcompat, we could add a new  '-incoming managed' as
> > being equivalent to '-incoming defer' but without the
> > implicit exit.
> > 
> 
> Probably, that's the best variant. As I can check libvirt in some case, but 
> not at all cases. And libvirt is not the only vm manager finally.
> And we can in the same time deprecate "-incoming defer" in favor of new 
> behavior.

Or just make it a new migration parameter?  Then we keep all existing
interfaces untouched, no risk of breaking anyone, and then it'll also apply
to anyone who uses things like -incoming tcp but still wants to keep the
qemu instance alive?

Thanks,

-- 
Peter Xu