From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=46728 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPJHO-00016h-9z for qemu-devel@nongnu.org; Thu, 17 Jun 2010 13:53:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPJHM-0007UI-UE for qemu-devel@nongnu.org; Thu, 17 Jun 2010 13:53:30 -0400 Received: from mail-vw0-f45.google.com ([209.85.212.45]:32963) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPJHM-0007U2-RQ for qemu-devel@nongnu.org; Thu, 17 Jun 2010 13:53:28 -0400 Received: by vws5 with SMTP id 5so769908vws.4 for ; Thu, 17 Jun 2010 10:53:27 -0700 (PDT) Message-ID: <4C1A6113.8090605@codemonkey.ws> Date: Thu, 17 Jun 2010 12:53:23 -0500 From: Anthony Liguori MIME-Version: 1.0 References: <20100609175215.2e2071a0@redhat.com> <20100611113022.27490bfe@redhat.com> <4C1636BC.704@linux.vnet.ibm.com> <4C165482.6020601@linux.vnet.ibm.com> <4C167DE4.8080104@linux.vnet.ibm.com> <4C168A81.8060302@codemonkey.ws> <20100615104047.260b7276@redhat.com> <20100616150155.49acbc50@redhat.com> <20100617112307.53482385@redhat.com> <20100617134527.12ed3eb8@redhat.com> In-Reply-To: <20100617134527.12ed3eb8@redhat.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: [Qemu-devel] Re: [PATCH v3 0/5] Add QMP migration events List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Luiz Capitulino Cc: qemu-devel@nongnu.org, Juan Quintela On 06/17/2010 11:45 AM, Luiz Capitulino wrote: > On Thu, 17 Jun 2010 18:34:00 +0200 > Juan Quintela wrote: > > >> Luiz Capitulino wrote: >> >>> On Wed, 16 Jun 2010 21:10:04 +0200 >>> Juan Quintela wrote: >>> >>> >>>> Luiz Capitulino wrote: >>>> >>>>> On Tue, 15 Jun 2010 17:24:59 +0200 >>>>> Juan Quintela wrote: >>>>> >>>> >>>>>>> I still don't see the need for MIGRATION_STARTED, it could be useful in >>>>>>> the target but I'd like to understand the use case in more detail. >>>>>>> >>>>>> At this point, if you are doing migration with tcp, and you are putting >>>>>> the wrong port on source (no path or any other error), you get no info >>>>>> at all of what is happening. >>>>>> >>>>> Shouldn't the migrate command just the return the expected error? >>>>> >>>> No. Think you are "having troubles". You try to find what happens. >>>> launch things by hand. And there is no way to know if anybody has >>>> conected to the destination machine. Some notification that migration >>>> has started is _very_ useful. expecially when there are >>>> networks/firewalls/... in the middle. >>>> >>> [...] >>> >>> >>>> That is it. But you continue telling that going to the old house and >>>> doing a info migrate is a good interface. >>>> >>> I'm sorry? When did I ever claimed such a thing? >>> >> polling is enough. polling has to be done in source machine. >> > Enough for the meantime, until we have something better to offer. The problem > here is that adding not so good stuff to a protocol is that we will have to > maintain it for a quite long time, possibly forever. > > That's why I'm being so opposed to a large set of events, a reduced set is a lot > more attractive. > > >>> First point: all you describe is MIGRATION_CONNECTED, at the end of the day >>> it would do exactly what you want for MIGRATION_STARTED. >>> >>> The second, and most important point, is that we're trying not to make >>> things worse. Adding a number of events to circumvent a bad designed >>> command and having the wrong expectations (ie. help developer debugging) >>> is a clear recipe for disaster. >>> >>> Anyway, I think it doesn't matter anymore, as QMP is not going to be declared >>> stable for 0.13. In this case we'll have enough time to design the proper >>> interface. >>> >>> >>>> To add insult to injury, the problem is that libvirt people are not >>>> collaborative, and expect things that can't be done, are uncooperative, >>>> >>> Again, I've never claimed that and I think you're taking this thread to >>> the wrong direction. >>> >> Ok, I stop then. >> > I'm not asking you to stop arguing, just to avoid taking the non-technical > route in a bad way. > > Now, we have the following situation: MIGRATION_CONNECTED and MIGRATION_DONE > would have possibly been a good fit for 0.13 if QMP was going to be stable. > > However, that's not going to happen so the question is: is it interesting > to have those events for an unstable QMP? Do we expect any client to need it? Or > can we wait until 0.14? > We need MIGRATION_CONNECTED post 0.13. We won't need MIGRATION_DONE so there's probably no point in introducing it. Regards, Anthony Liguori