Re: [Qemu-devel] [PATCH v2 10/11] block: add option 'backing' to -drive options

[Ian Main]

On Wed, Jul 17, 2013 at 05:09:05PM +0200, Kevin Wolf wrote:
> Am 17.07.2013 um 16:16 hat Paolo Bonzini geschrieben:
> > Il 17/07/2013 15:48, Kevin Wolf ha scritto:
> > >> I understand this is the right thing to do long term, but pre-opening of
> > >> the target is not really needed for fleecing.
> > > 
> > > So for how much longer should we plan to procrastinate? (I know, not an
> > > entirely fair question, but we have to make the step at some point)
> > 
> > If we bring it up during soft freeze, we will procrastinate it a lot. :)
> >  If we bring it up at the beginning of a release cycle, the wait could
> > be as short as 1 month...
> > 
> > > And we'll want to reference existing BDSes as backing/protocol files in
> > > blockdev-add soon anyway, so if we decide against it here, it's just
> > > moving from Fam's to-do list to mine...
> > 
> > We can reconsider these very patches in 1 month.  It's just the timing,
> > combined with the fact that this is not necessary for fleecing, that I'm
> > uncomfortable with.
> 
> Okay, I see where this is going. Let me reinforce one fundamental policy
> that you may not like. I've rejected patches based on it before and I'll
> likely have to do it again in the future. This is it:
> 
>     I'm not going to compromise on upstream APIs to accommodate
>     downstream schedules.
> 
> If doing things properly means moving fleecing to 1.7, so be it. There's
> no pressure to have it in upstream 1.6. It might mean downstream patches
> for some distro, but that's not a valid point in upstream design
> discussions.

I'll just throw out there that *I'm* feeling pressure for 1.6, but at
the same time I understand your concerns.  Some feel that independent of
distro concerns this is a feature gap for KVM/qemu.

It seems to me a practical approach of taking what is needed to get this
working while also putting out patches for doing it right would work out
well in the end.

Anyway, just my 2c.  I am just helping out and I know you guys have to
deal with the long term effects so I respect your decisions. 

        Ian

> Now is the right time to discuss design changes for 1.7, so that as soon
> as block-next starts to come to life (i.e. beginning of August), we can
> start with implementing this at the earliest possible point in the 1.7
> release cycle.
> 
> > > I guess we can give a name to the target, and we can make drive-backup
> > > automatically connect the target with the original as its backing file
> > > (still needs the refcounting, by the way).
> > 
> > No, it doesn't need the refcounting (see my reply to the cover letter).
> >  In his next submission of drive-backup sync modes, Ian is already going
> > to handle the automatic connection of the target with the original.
> 
> Okay, I'll have a look, but I can't imagine how it work without
> refcounting. As soon as it has a name, you can attach the target to a
> guest, nbd server, start block jobs and do all kinds of fun with it so
> that taking it away when the source goes away becomes problematic. But
> I'll have a look at the patches and hope that the commit messages
> explain the details.
> 
> > > But is giving a name to the
> > > target not enough to allow "interesting" things to be done? I don't
> > > remember the details from the mirroring discussion, but it seems it were
> > > enough that you didn't want to do it.
> > 
> > Yes, but this time we have to bite the bullet on that one at least,
> > because we have no other choice (we want to do at least one
> > "interesting" thing, namely connect to it with the NBD server).
> 
> Yes, like I said, we might not feel comfortable with enabling these
> cases, but not enabling them isn't an option either. So now is the time
> to do the real thing.
> 
> Kevin