[Engine-devel] Cluster default with empty processor name with PPC64 support

[Itamar Heim]

On 09/03/2013 02:39 PM, Leonardo Bianconi wrote:
>
>
>> -----Original Message-----
>> From: Itamar Heim [mailto:iheim at redhat.com]
>> Sent: segunda-feira, 2 de setembro de 2013 13:46
>> To: Leonardo Bianconi
>> Cc: Roy Golan; engine-devel at ovirt.org
>> Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>>
>> On 09/02/2013 06:43 PM, Leonardo Bianconi wrote:
>>>
>>>
>>>> -----Original Message-----
>>>> From: Itamar Heim [mailto:iheim at redhat.com]
>>>> Sent: segunda-feira, 2 de setembro de 2013 10:29
>>>> To: Leonardo Bianconi
>>>> Cc: Roy Golan; engine-devel at ovirt.org
>>>> Subject: Re: [Engine-devel] Cluster default with empty processor name
>>>> with PPC64 support
>>>>
>>>> On 09/02/2013 03:35 PM, Leonardo Bianconi wrote:
>>>>>
>>>>>
>>>>>>> From: Roy Golan [mailto:rgolan at redhat.com]
>>>>>>> Sent: domingo, 1 de setembro de 2013 05:07
>>>>>>> To: Leonardo Bianconi
>>>>>>> Cc: engine-devel at ovirt.org
>>>>>>> Subject: Re: [Engine-devel] Cluster default with empty processor
>>>>>>> name with PPC64 support
>>>>>>>
>>>>>>> On 08/30/2013 10:51 PM, Leonardo Bianconi wrote:
>>>>>>> Hi everyone!
>>>>>>>
>>>>>>> During the development of PPC64 support in the engine, we faced
>>>>>>> some UX issues regarding the default Cluster (that Cluster with
>>>> empty processor name).
>>>>>>>
>>>>>>> Currently, oVirt engine allows the default Cluster to contain
>>>>>>> empty processor name, and the administrator can add VMs and/or
>>>> Templates to it. The processor name can be assigned later, editing the cluster or assigning a valid host to it.
>>>>>>>
>>>>>>> During the implementation of PPC64 support on the engine, the
>>>>>>> field "architecture" was added to Clusters, VMs and Templates
>>>> entities.
>>>>>>> herdado
>>>>>>> So we have the following questions regarding how the UI should behave:
>>>>>>>
>>>>>>> - Shall we keep allowing the administrator to assign VMs and
>>>>>>> Templates to the Cluster with no processor name or assigned
>>>> architecture ?
>>>>>>>                 -> If we have an "yes" for the question above:
>>>>>>>                 -- We will have to assign the architecture to the
>>>>>>> Cluster based on the OS of the first assigned VM, and  the
>>>>>>> processor name
>>>> could be defined the same way as currently ... editing the Cluster or assigning a compatible Host to it.
>>>>>>>                                 -- The VM creation popup will have
>>>>>>> to be able to indicate the architecture of each OS ... some OSes
>>>>>>> have the same
>>>> name, and it may get ambiguous since the Cluster architecture is still undefined at that point (before the first VM get already
>> created).
>>>>>>>
>>>>>>> Thanks!
>>>>>>> Regards.
>>>>>>> Leonardo Bianconi
>>>>>>>
>>>>>> To add VMs you anyway need a running host in the cluster which means the cpu name and the architecture would be the host's.
>>>>>> So we can keep the cluster attributes - "cpu name" and "arch" consistent and allow them to be empty on creation.
>>>>>>
>>>>>>
>>>>> Hi Roy!
>>>>>
>>>>> There is a way to add VMs in a cluster with no hosts running. Steps to reproduce:
>>>>> - Initialize the oVirt engine with a new data base
>>>>> - Create a new Cluster (I will call it of newCluster) in the Data
>>>>> Center Default
>>>>> - Add a host in the newCluster
>>>>> - Add a Storage
>>>>> - Create a VM in the Cluster Default
>>>>> Result: The system allows a VM in a cluster with no Hosts running in it.
>>>>>
>>>>> Is it a bug or a system functionality? If it's a functionality, the issue above can happen.
>>>>
>>>> while above can happen, is it really an interesting use case to solve?
>>>> can user edit the arch field of a vm? if so, i'd just block running
>>>> it on incorrect cluster (just like we block on moving it between
>>>> incompatible clusters) until user fix the issue
>>>
>>> Yes, it's interesting solve, because we use the cluster architecture when creating VMs.
>>> The user cannot edit the arch field, because there is no field for that, it is inherited from the cluster. The arch is important on
>> creating VMs, because it filters the OS list and defines the VM architecture.
>>> What should we do?
>>>
>>> Thanks!!
>>>
>>
>> so worst case the list is not filtered while creating the VM for that corner case?
>>
>> thinking about this some more, with all due respect to PPC and this corner case, I'd just assume if cluster arch is not yet defined, OS list
>> should be filtered as x86_64.
>> or, we block creating VMs on clusters which have no arch defined (I'm specifically not saying no hosts, just in case its useful somehow)
>
> I think both are good solutions, but looking the system behavior, I think the first solution will be weird for new users and the second has problems when upgrading the data base.
> I would suggest the following behavior:
>
> 1. For new data bases: Block the admin to add VMs in the cluster with no processor name (Cluster Default), i. e. no architecture.
> 2. For upgraded data bases, If the cluster with no processor name (Cluster Default) has:
>    2.1 - VMs: Set the cluster architecture for x86_64 and allow admin use it as x86_64.
>    2.2 - no VMs: Keep the cluster with no processor name, i. e. no architecture (it will keep the same behavior of the cluster for new data base - item 1)
>
> On the item 2.1, when setting the architecture of the cluster (Cluster Default) for x86_64, the processor name will be empty. Should we set it for the lowest x86_64 level?
>
> What do you think?
>
> Thanks!!
>

sounds good to me. roy/omer/michal?