From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from [140.186.70.92] (port=44668 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1OPINV-0001O6-D5 for qemu-devel@nongnu.org; Thu, 17 Jun 2010 12:55:46 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1OPINR-0005KR-N8 for qemu-devel@nongnu.org; Thu, 17 Jun 2010 12:55:45 -0400 Received: from mx1.redhat.com ([209.132.183.28]:45736) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1OPINR-0005KB-F0 for qemu-devel@nongnu.org; Thu, 17 Jun 2010 12:55:41 -0400 Date: Thu, 17 Jun 2010 13:45:27 -0300 From: Luiz Capitulino Message-ID: <20100617134527.12ed3eb8@redhat.com> In-Reply-To: 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> Mime-Version: 1.0 Content-Type: text/plain; charset=US-ASCII 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: Juan Quintela Cc: qemu-devel@nongnu.org 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?