Bug 1149094

Summary:	Supposedly cancelled, yet completed change of cluster
Product:	Red Hat Enterprise Virtualization Manager	Reporter:	Tomas Jamrisko <tjamrisk>
Component:	ovirt-engine	Assignee:	Andrej Krejcir <akrejcir>
Status:	CLOSED CURRENTRELEASE	QA Contact:	Artyom <alukiano>
Severity:	unspecified	Docs Contact:
Priority:	unspecified
Version:	3.5.0	CC:	akrejcir, dfediuck, gklein, lsurette, mavital, rbalakri, rgolan, Rhev-m-bugs, sherold, srevivo, ykaul
Target Milestone:	ovirt-3.6.0-rc3	Keywords:	Triaged, ZStream
Target Release:	3.6.0	Flags:	rgolan: needinfo-
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:
Clones:	1273037 (view as bug list)		Environment:
Last Closed:	2016-04-20 01:36:44 UTC	Type:	Bug
Regression:	---	Mount Type:	---
Documentation:	---	CRM:
Verified Versions:		Category:	---
oVirt Team:	SLA	RHEL 7.3 requirements from Atomic Host:
Cloudforms Team:	---	Target Upstream Version:
Embargoed:
Bug Depends On:
Bug Blocks:	1273037

Description Tomas Jamrisko 2014-10-03 08:30:52 UTC

Description of problem:
Two clusters, different hardware, one of them with 6.6 hosts, the other uses 7.1.
Attempt to change cluster of a VM results with the following error window:

┌---------------------------------------------┐
|X Operation cancelled                        |
|                                             |
|Error while executing action:                |
|                                             |
|$(vm_name):                                  |
| • ACTION_TYPE_CPU_PROFILE_NOT_MATCH_CLUSTER |
└---------------------------------------------┘

Which is sort of weird, as the cluster gets successfully changed anyway.

Version-Release number of selected component (if applicable):
vt4 (3.5.0-0.13.beta)

How reproducible:
100%

Steps to Reproduce:
1. Change VM's cluster, to one with with different specs.

Actual results:
The message and changed cluster

Expected results:
No message, changed cluster, or, technically wrong -- but still better,
message but same cluster.

Comment 1 Roy Golan 2014-10-08 08:12:48 UTC

I assume the VM has a cpu profile attached which doesn't exist under the target cluster. 

Scott what do we want to happen, succesful change of Vm cluster with some unknown profile or fail the change as the current Vm properties couldn't be fulfilled? 

I'm not sure how consistent we are with other VM properties that are missing when switching clusters. like network for example.

Comment 2 Scott Herold 2015-01-27 11:10:10 UTC

(In reply to Roy Golan from comment #1)
> I assume the VM has a cpu profile attached which doesn't exist under the
> target cluster. 
> 
> Scott what do we want to happen, succesful change of Vm cluster with some
> unknown profile or fail the change as the current Vm properties couldn't be
> fulfilled? 
> 
> I'm not sure how consistent we are with other VM properties that are missing
> when switching clusters. like network for example.

Is it possible to do the successful change of the cluster for the VM, with the following logic?
 
  *  If the cpu profile exists in the target cluster, move successful, no notification

  * If the cpu profile does not exist in target cluster, move successful, but message to user that CPU no longer has profile associated since it is missing from the target cluster

Comment 3 Roy Golan 2015-01-27 11:43:20 UTC

(In reply to Scott Herold from comment #2)
> (In reply to Roy Golan from comment #1)
> > I assume the VM has a cpu profile attached which doesn't exist under the
> > target cluster. 
> > 
> > Scott what do we want to happen, succesful change of Vm cluster with some
> > unknown profile or fail the change as the current Vm properties couldn't be
> > fulfilled? 
> > 
> > I'm not sure how consistent we are with other VM properties that are missing
> > when switching clusters. like network for example.
> 
> Is it possible to do the successful change of the cluster for the VM, with
> the following logic?
>  
>   *  If the cpu profile exists in the target cluster, move successful, no
> notification
> 
>   * If the cpu profile does not exist in target cluster, move successful,
> but message to user that CPU no longer has profile associated since it is
> missing from the target cluster

we're almost there. the cluster is changed, the rest of the vm update fails. so now, what profile should we choose? we see that in lots of other scenraio with profiles - disk move to another domain, vnics on another cluster as well. 

we have 2 options I think - 
1. to have a "default" attribute on a profile so we can choose it automatically and assign it in case was not specify.

2. to treat null as profile - conceptually its a default profile but unmanageble


I prefer option 1

Comment 4 Scott Herold 2015-01-27 12:47:20 UTC

(In reply to Roy Golan from comment #3)
> (In reply to Scott Herold from comment #2)
> > (In reply to Roy Golan from comment #1)
> > > I assume the VM has a cpu profile attached which doesn't exist under the
> > > target cluster. 
> > > 
> > > Scott what do we want to happen, succesful change of Vm cluster with some
> > > unknown profile or fail the change as the current Vm properties couldn't be
> > > fulfilled? 
> > > 
> > > I'm not sure how consistent we are with other VM properties that are missing
> > > when switching clusters. like network for example.
> > 
> > Is it possible to do the successful change of the cluster for the VM, with
> > the following logic?
> >  
> >   *  If the cpu profile exists in the target cluster, move successful, no
> > notification
> > 
> >   * If the cpu profile does not exist in target cluster, move successful,
> > but message to user that CPU no longer has profile associated since it is
> > missing from the target cluster
> 
> we're almost there. the cluster is changed, the rest of the vm update fails.
> so now, what profile should we choose? we see that in lots of other scenraio
> with profiles - disk move to another domain, vnics on another cluster as
> well. 
> 
> we have 2 options I think - 
> 1. to have a "default" attribute on a profile so we can choose it
> automatically and assign it in case was not specify.

Would this also require that whatever we dictate as default also be located across every cluster, which we may not be able to guarantee?

> 
> 2. to treat null as profile - conceptually its a default profile but
> unmanageble

This seems like it would be the item that would guarantee the VM would properly start.

> 
> 
> I prefer option 1

Comment 5 Roy Golan 2015-01-27 14:37:04 UTC

> > we have 2 options I think - 
> > 1. to have a "default" attribute on a profile so we can choose it
> > automatically and assign it in case was not specify.
> 
> Would this also require that whatever we dictate as default also be located
> across every cluster, which we may not be able to guarantee?

I say that we'll give the Admin the option to set a profile as default.  instead of managing 

it has some complexity I guess - a default profile must be publically visible i.e permission of everyone on it. so when deleting it we need to make sure we have an alternative. 

and make sure when someone configures a profile as default, we grant everyone permission on it.

Comment 6 Eyal Edri 2015-02-25 08:39:47 UTC

3.5.1 is already full with bugs (over 80), and since none of these bugs were added as urgent for 3.5.1 release in the tracker bug, moving to 3.5.2

Comment 7 Eyal Edri 2015-04-28 11:21:59 UTC

moving to 3.5.4 due to capacity planning for 3.5.3.
if you believe this should remain in 3.5.3, please sync with pm/dev/qe and a full triple ack for it. also - ensure priority is set accordingly.

Comment 8 Roy Golan 2015-10-19 10:47:25 UTC

Following Bug 1262293 in 3.6 we always pick the 1st profile in the list.

This should have the same behaviour currently.

downport the patch to 3.5.6

Comment 9 Roy Golan 2015-10-19 12:33:52 UTC

on QA due to fix from Bug 1262293.

Comment 11 Artyom 2015-10-25 12:37:49 UTC

Verified on rhevm-3.6.0.2-0.1.el6.noarch
Change cluster also change cpu_profile of vm to one from cluster.