On Thu, Jul 15, 2010 at 05:25:05PM +0100, Guido Trotter wrote: > On Thu, Jul 15, 2010 at 5:22 PM, Iustin Pop <[email protected]> wrote: > > On Thu, Jul 15, 2010 at 18:18, Guido Trotter <[email protected]> wrote: > >> On Thu, Jul 15, 2010 at 5:09 PM, Iustin Pop <[email protected]> wrote: > >>> Since migration live/non-live is more stable (e.g.) for Xen-PVM versus > >>> Xen-HVM, we introduce a new parameter for what mode we should use by > >>> default (if not overridden by the user, in the opcode). > >>> > >>> The meaning of the opcode 'live' field changes from boolean to either > >>> None (use the hypervisor default), or one of the allowed migration > >>> string constants. The live parameter of the TLMigrateInstance is still a > >>> boolean, computed from the opcode field (which is no longer passed to > >>> the TL). > >> > >> LGTM > >> > >> Just wondering: > >> > >>> + if self.lu.op.live is None: > >>> + # read the default value from the hypervisor > >>> + i_hv = self.cfg.GetClusterInfo().FillHV(instance, > >>> skip_globals=False) > >>> + self.lu.op.live = i_hv[constants.HV_MIGRATION_TYPE] > >>> + > >> > >> Does it make sense to calculate this here, or should we just leave it > >> to the hypervisor code (and just pass on the overriding value, if we > >> got any?). > > > > It would mean to be replicated in a couple of places (via a common > > function, of course), and today it doesn't give us any advantage over > > plain boolean. If the modes would mean different things for various > > hypervisors, or if e.g. lxc would have a different mode (snapshot), > > then yes. > > True as well. But then we have a new place where we fill/calculate the > hv params, while the hypervisors already do that.
But I do not think it's the hypervisor job to know about the structure of the CLI/cluster (we have a default, the user might override it, etc.). Basically this should purely be a HV param, and override via the -H migration-type=live, and then we wouldn't have a need for the 'extra' value in the RPC call, etc. Hmm… iustin
