From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=36020 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1ON5Ni-0001z2-Hn for qemu-devel@nongnu.org; Fri, 11 Jun 2010 10:38:56 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1ON5Nf-0007YR-2G for qemu-devel@nongnu.org; Fri, 11 Jun 2010 10:38:50 -0400 Received: from mail-iw0-f173.google.com ([209.85.214.173]:38796) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1ON5Ne-0007YD-SJ for qemu-devel@nongnu.org; Fri, 11 Jun 2010 10:38:47 -0400 Received: by iwn10 with SMTP id 10so1235192iwn.4 for ; Fri, 11 Jun 2010 07:38:45 -0700 (PDT) Message-ID: <4C124A72.9000807@codemonkey.ws> Date: Fri, 11 Jun 2010 09:38:42 -0500 From: Anthony Liguori MIME-Version: 1.0 Subject: Re: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> In-Reply-To: <20100611113022.27490bfe@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: aliguori@us.ibm.com, qemu-devel@nongnu.org, Juan Quintela On 06/11/2010 09:30 AM, Luiz Capitulino wrote: > On Thu, 10 Jun 2010 12:44:55 +0200 > Juan Quintela wrote: > > >> Luiz Capitulino wrote: >> >>> On Wed, 9 Jun 2010 14:10:53 +0200 >>> Juan Quintela wrote: >>> >>> >>>> This is a resent with what we agreed on yesterday call. >>>> Migration events would be there for 0.13 until we get proper >>>> async command support. >>>> >>> Something which is not clear to me is the set of events we'd have if migrate >>> was an async command. >>> >>> Ie, do we really need MIGRATION_FAILED in this case? Don't we expect to get >>> this information from the async response? >>> >>> >> I am not able to define simpler semantics for this events: >> > Ok, I must be missing something here. > > First, let's talk about how async commands work today, better yet, how they > should work in 0.14. > > I see two possible interfaces (off the top of my head): > > 1. QMP only returns the response when the command is finished, eg: > > C: { "execute": "migrate", "id": "foo" ... } > /* nothing is returned, other commands are issued, after several hours... */ > S: { "return": ... "id": "foo" } > This is how just about every RPC mechanism works... > 2. QMP returns a response right away just to signal that the command > has been accepted: > > C: { "execute": "migrate", "id": "foo" ... } > S: { "return": {}, "id": "foo" ... } > > However, the actual response is emitted as an event: > > S: { "event": "ASYNC_RESPONSE", "return": ..., "id": "foo" } > That's quite unusual and I don't see why it would be necessary. It adds quite a bit of complexity because now clients have to handle to distinct error conditions instead of one. >> - MIGRATION_STARTED: somebody started a migration, it is emited on >> source and target, all monitors receive this event. >> > The client has started the migration, it knows it. Why is the event needed? > I think we've more or less agreed that MIGRATION_CONNECTED is really the event we want. >> - 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. >> 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. Regards, Anthony Liguori