From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:38348) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1btxAa-00073a-FA for qemu-devel@nongnu.org; Tue, 11 Oct 2016 09:32:37 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1btxAY-0006z1-Dn for qemu-devel@nongnu.org; Tue, 11 Oct 2016 09:32:35 -0400 Date: Tue, 11 Oct 2016 15:32:23 +0200 From: Kashyap Chamarthy Message-ID: <20161011133223.tgbbwqbwnj7lhs5n@eukaryote> References: <1475272849-19990-1-git-send-email-jsnow@redhat.com> <1475272849-19990-3-git-send-email-jsnow@redhat.com> <20161005134312.GA1657@noname.str.redhat.com> <0e9d9739-b32b-8cff-3e34-ccc8e971b4c3@redhat.com> <2a33be0f-1f42-dd3c-93c2-2306811ea757@redhat.com> <20161010164542.xze564cbscx4t2up@eukaryote> <69d01f9f-0f41-c407-9bdc-4d43f34298e1@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <69d01f9f-0f41-c407-9bdc-4d43f34298e1@redhat.com> Subject: Re: [Qemu-devel] [PATCH v2 02/11] blockjob: centralize QMP event emissions List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Eric Blake Cc: John Snow , Kevin Wolf , vsementsov@virtuozzo.com, famz@redhat.com, qemu-block@nongnu.org, jcody@redhat.com, qemu-devel@nongnu.org, stefanha@redhat.com On Mon, Oct 10, 2016 at 02:28:52PM -0500, Eric Blake wrote: > On 10/10/2016 01:36 PM, John Snow wrote: [...] > > I'll be honest that I don't know; this is related to Replication which I > > know reasonably little about overall. It got added in the 2.8 timeframe, > > so the behavior it currently exhibits is not a good or meaningful > > reference for maintaining compatibility. > > > > We can /change/ the behavior before releases with no love lost. > > And if Replication is the only way to trigger internal use of jobs, then > we aren't breaking libvirt (which doesn't know how to drive replication > yet) by changing anything on that front. Exactly. > > Or, what if you just didn't get events for internal jobs? Are events for > > un-managed jobs useful in any sense beyond understanding the stateful > > availability of the drive to participate in a new job? > > If libvirt isn't driving replication, then it's a moot point. And even > though replication in libvirt is not supported yet, I suspect that down > the road when support is added, the easiest thing for libvirt will be to > state that replication and libvirt-controlled block jobs are mutually > exclusive; there's probably enough lurking dragons that if your system > MUST be high-reliance by replication, you probably don't want to be > confusing things by changing the backing file depth manually with > streams, pulls, or other manual actions at the same time as replication > is managing the system, because how can you guarantee that both primary > and secondary see the same manual actions at all the right times? Very nice argument for making them mutually exclusive, from a libvirt POV. > At any rate, not seeing internal-only jobs is probably the most > reasonable, even if it means an internal-only job can block the attempt > to do a manual job. FWIW, I agree, if only as a user / observer of these events during debugging. [...] -- /kashyap