* Juan Quintela (quint...@redhat.com) wrote:
> "Dr. David Alan Gilbert" <dgilb...@redhat.com> wrote:
> > * Juan Quintela (quint...@redhat.com) wrote:
> >> Markus Armbruster <arm...@redhat.com> wrote:
> >> > Juan Quintela <quint...@redhat.com> writes:
> >> >
> >> >> Eric Blake <ebl...@redhat.com> wrote:
> >>
> >>
> >> >>> Or is the proposal that we are also going to simplify the QMP 'migrate'
> >> >>> command to get rid of crufty parameters?
> >> >>
> >> >> I didn't read it that way, but I would not oppose O:-)
> >> >>
> >> >> Later, Juan.
> >> >
> >> > I'm not too familiar with this stuff, so please correct my
> >> > misunderstandings.
> >> >
> >> > "Normal" migration configuration is global state, i.e. it applies to all
> >> > future migrations.
> >> >
> >> > Except the "migrate" command's flags apply to just the migration kicked
> >> > off by that command.
> >> >
> >> > QMP command "migrate" has two flags "blk" (HMP: -b) and "inc" (HMP: -i).
> >> > !blk && inc makes no sense and is silently treated like !blk && !inc.
> >> >
> >> > There's a third flag "detach" (HMP: -d), but it does nothing in QMP.
> >>
> >> As qmp command is asynchronous, you can think that -d is *always* on in
> >> QMP O:-)
> >>
> >> > You'd like to deprecate these flags in favour of "normal" configuration.
> >> > However, we need to maintain QMP backward compatibility at least for a
> >> > while. HMP backward compatibility is nice to have, but not required.
> >> >
> >> > First step is to design the new interface you want. Second step is to
> >> > figure out backward compatibility.
> >> >
> >> > The new interface adds a block migration tri-state (off,
> >> > non-incremental, incremental) to global state, default off. Whether
> >> > it's done as two bools or an enum of three values doesn't matter here.
> >>
> >> Tristates will complicate it. I still think that:
> >>
> >> - capability: block_migration
> >> - parameter: block_shared
> >>
> >> Makes more sense, no?
> >
> > I don't understand what making block_shared a parameter gives you as
> > opposed to simply having two capabilities.
> >
> > (And how did we get 'shared'? We started off with block & incremental)
>
> The variables on MigrationParams:
>
> struct MigrationParams {
> bool blk;
> bool shared;
> };
>
>
> I can move to incremental. I am not sure which one is clearer.
>
> The advantage of having shared as a parameter is that we forget about
> all this dependency bussiness. Is the same than compression_threads
> paramter, you setup to whichever value that you want. But you don't get
> compression_threads until you set the compress capability.
>
> So, in this case we will have:
>
> block capability: Are we using block migration or not
> block-incremental parameter: If we are using block migration, are we
> using incremental copying of the block layer?
If it's still a boolean why does having it as a parameter remove the
dependency?
Dave
>
> Later, Juan.
--
Dr. David Alan Gilbert / dgilb...@redhat.com / Manchester, UK
