-----Original Message----- From: Michal Skrivanek [mailto:mskrivan@redhat.com] Sent: terça-feira, 3 de setembro de 2013 09:19 To: Leonardo Bianconi Cc: engine-devel(a)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(a)redhat.com&gt; wrote: > On 09/03/2013 02:39 PM, Leonardo Bianconi wrote: >> >> >>> -----Original Message----- >>> From: Itamar Heim [mailto:iheim@redhat.com] >>> Sent: segunda-feira, 2 de setembro de 2013 13:46 >>> To: Leonardo Bianconi >>> Cc: Roy Golan; engine-devel(a)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@redhat.com] >>>>> Sent: segunda-feira, 2 de setembro de 2013 10:29 >>>>> To: Leonardo Bianconi >>>>> Cc: Roy Golan; engine-devel(a)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@redhat.com] >>>>>>>> Sent: domingo, 1 de setembro de 2013 05:07 >>>>>>>> To: Leonardo Bianconi >>>>>>>> Cc: engine-devel(a)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?

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

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