Am 23.12.2015 um 09:33 hat Stefan Hajnoczi geschrieben: > On Fri, Dec 18, 2015 at 02:15:38PM +0100, Markus Armbruster wrote: > > What should happen when the user asks for a mutation at a place where we > > have implicit filter(s)? > > Please suspend your disbelief for a second: > > In principle it's simplest not having implicit filters. The client > needs to set up throttling nodes or the backup filter explicitly. > > Okay, now it's time to tear this apart: > > For backwards compatibility it's necessary to support throttling, > copy-on-read, backup notifier, etc. It may be possible to tag implicit > filter nodes so that mutation operations that wouldn't be possible today > are rejected. The client must use the explicit syntax to do mutations > on implicit filters. This is easier said than done, I'm not sure it can > be implemented cleanly.
Yes, backwards compatibility is what complicates things a bit. > Another problem is that the backup block job and other operations that > require a single command today could require sequences of low-level > setup commands to create filter nodes. The QMP client would need to > first create a write notifier filter and then start the backup block job > with the write notifier node name. It's clumsy. I don't think splitting it up into several low-level commands is necessary. We don't expect the user to set any options for the filter (and if we did, they would probably have to match the same options for the block job), so we can keep the BDS creation as a part of starting the block job. The important part is that the management tool knows that a filter is going to be inserted and how to address it. In order to achieve that, we could simply add a 'filter-node-name' option to the QMP command starting the job. Kevin
pgp5FS6ENXitq.pgp
Description: PGP signature
