[Engine-devel] cluster emulation mode feature
Omer Frenkel
ofrenkel at redhat.com
Thu Jun 6 12:09:59 UTC 2013
----- Original Message -----
> From: "Roy Golan" <rgolan at redhat.com>
> To: "Omer Frenkel" <ofrenkel at redhat.com>
> Cc: engine-devel at ovirt.org
> Sent: Thursday, June 6, 2013 12:33:26 PM
> Subject: Re: [Engine-devel] cluster emulation mode feature
>
> On Thu 06 Jun 2013 10:20:30 AM IDT, Omer Frenkel wrote:
> >
> >
> > ----- Original Message -----
> >> From: "Roy Golan" <rgolan at redhat.com>
> >> To: engine-devel at ovirt.org
> >> Sent: Thursday, June 6, 2013 8:17:54 AM
> >> Subject: [Engine-devel] cluster emulation mode feature
> >>
> >> Hi,
> >>
> >> A new wiki has been published on Cluster Emulation mode
> >> http://www.ovirt.org/Cluster_emulation_modes
> >>
> >> Please review.
> >>
> >> Thanks,
> >> Roy
> >> _______________________________________________
> >> Engine-devel mailing list
> >> Engine-devel at ovirt.org
> >> http://lists.ovirt.org/mailman/listinfo/engine-devel
> >>
> >
> > maybe better to name host field as supported_emulated_machines - since it
> > holds the list of supported as reported from vdsm.
> >
> will change if this seems clearer
seems clearer to me.
> > the following is a copy from the wiki
> > "
> > consider this pseudo-code:
> >
> > operational = false
> > if cluster.emulationMode == NULL
> > for configVal in Config.ClusterEmulationMode(3.3)
> > if configVal in host.emulationModes
> > cluster.emulationMode = configVal
> > operational = true
> > else if clusterEmulationMode in host.emulationMode
> > operational = true
> > if (!operational)
> > set host non operationl, reason = UNSUPPORTED_EMULATION_MODE
> > "
> >
> > first, i guess where you write '3.3' its actually should be
> > 'cluster.compatibility'
> yes its just a visual notion of the version
> > another thing, the configuration will probably have more than 1 option for
> > emulated machine,
> > for example 3.3 rhel could have {(for EL-)RHEL6.4.0,RHEL6.3.0,..,(for
> > other-)pc-1.3,pc-1.2..}
> > we need to make sure the list is used ordered so that the greatest value
> > will be first,
> > since if host supports many, the latest will be used.
> > in cpu-flags there is a specific number to do this order, maybe same
> > approach can be taken here,
> > as i'm not sure the RHEL/pc values are consistent (on my f18 i also have
> > 'pc-i440fx-1.4')
> isn't the order of the list enough?
>
basically yes, it means we assume users who will change it will be aware the order matters.
im ok with that because i assume not many changes will be done here (as this just the defaults)
More information about the Devel
mailing list