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

Tue Sep 3 12:25:23 UTC 2013

>-----Original Message-----
>From: Michal Skrivanek [mailto:mskrivan at redhat.com]
>Sent: terça-feira, 3 de setembro de 2013 09:19
>To: Leonardo Bianconi
>Cc: engine-devel at ovirt.org
>Subject: Re: [Engine-devel] Cluster default with empty processor name with PPC64 support
>
>
>On Sep 3, 2013, at 13:49 , Itamar Heim <iheim at redhat.com> wrote:
>
>> 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.
>
>as an upgrade script, right?

Yes.

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

How about the processor name for this case, Any thoughts?

>
>sounds good enough
>
>Thanks,
>michal
>
>>>
>>> What do you think?
>>>
>>> Thanks!!
>>>
>>
>> sounds good to me. roy/omer/michal?
>> _______________________________________________
>> Engine-devel mailing list
>> Engine-devel at ovirt.org
>> http://lists.ovirt.org/mailman/listinfo/engine-devel