Anthony Liguori<address@hidden> wrote:
On 06/11/2010 09:30 AM, Luiz Capitulino wrote:
On Thu, 10 Jun 2010 12:44:55 +0200
Juan Quintela<address@hidden> wrote:
I think we've more or less agreed that MIGRATION_CONNECTED is really
the event we want.
This had the problem of migrating to a file/whatever.
Yes. Today, we should just generate a MIGRATION_DONE event and let a
client poll for failure status.
I disagree completely. It just defeat the reason for this.
MIGRATION_ENDED on destination machine: go ahead, everything is ok.
MIGRATION_FAILED: Uh, oh, something got wrong, we are in the slow path.
With MIGRATION_DONE + polling, we are delaying the "success" case just
to avoid having a new event. I don't buy it.
I still think that we want the 4 events that I described. My
understanding is that libvirt people also would love to have that 4
events.
Answer here is that: you can do this workaround and this other
workaround and you can get that information.
About semantics of messages, I don't see anytime soon that migration are
going to change from:
Start migration and then end with success or failure.
The only one that we could change/remove is MIGRATION_CANCEL to
MIGRATION_FAILURE(User canceled) it. But that is it.
Why have to do a polling when none is needed?
If you preffer to change the MIGRATION_ENDED + MIGRATION_FAILURE(error)
to MIGRATION_ENDED(result code), and you have to check the error code, I
can also live with that. But that is it.