[Engine-devel] cluster emulation mode feature

[Roy Golan]

On Thu 06 Jun 2013 03:09:59 PM IDT, Omer Frenkel wrote:
>
>
> ----- 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.
>

wiki updated

>>> 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)

great I like it simple here.