On 09/03/2013 02:39 PM, Leonardo Bianconi wrote:
-----Original Message-----
From: Itamar Heim [mailto:ih...@redhat.com]
Sent: segunda-feira, 2 de setembro de 2013 13:46
To: Leonardo Bianconi
Cc: Roy Golan; engine-devel@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:ih...@redhat.com]
Sent: segunda-feira, 2 de setembro de 2013 10:29
To: Leonardo Bianconi
Cc: Roy Golan; engine-devel@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:rgo...@redhat.com]
Sent: domingo, 1 de setembro de 2013 05:07
To: Leonardo Bianconi
Cc: engine-devel@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?
_______________________________________________
Engine-devel mailing list
Engine-devel@ovirt.org
http://lists.ovirt.org/mailman/listinfo/engine-devel
