Anthony Liguori <anth...@codemonkey.ws> wrote: > On 06/11/2010 09:30 AM, Luiz Capitulino wrote: >> On Thu, 10 Jun 2010 12:44:55 +0200 >> Juan Quintela<quint...@redhat.com> 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. MIGRATION_CONECTED only makes sense when you have TCP or similar. MIGRATION_STARTED it just means that migration has started, independently of whatever method you have. For TCP it is possible that we want another event each time that somebody connected to a port (not only for migration), but that is something different. >>> - MIGRATION_ENDED: migration ended with sucess, all needed data is in >>> target machine. Also emitted in all monitors on source and target. >>> >>> - MIGRATION_CANCELED: in one of the source monitors somebody typed: >>> migrate_cancel. It is only emmited on the source monitors, target >>> monitors will receive a MIGRATION_FAILED event. >>> >>> - MIGRATION_FAILED (with this error). At this point we don't have >>> neither the QMP infraestructure for sending (with this error) nor >>> migration infrastructure to put there anything different than -1. >>> >> Aren't all the three events above duplicating the async response? >> > > 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. >>> This event is emmited on all source and target monitors. >>> - For 0.13: Event don't have a QError. >>> - For 0.14: It will gain a QError. >>> >>> About migration becoming an async command. Really it is independent >>> of what events we emit. If migration becomes async command, only >>> difference is for the monitor that emitted the command, rest of >>> monitors see nothing. If we want to be able to see that informantion >>> in the other monitors, we need the events anyways. >>> >> Somewhere else in this discussion someone has said that we should assume >> that the client talking to the source is the same one which is going to >> talk to the target, in this case all the communication is done through >> the source qemu instance. >> > > MIGRATION_DONE gets deprecated for 0.14. 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. Later, Juan.