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
