Bug 1158458 - Failed to update VM Cluster
Summary: Failed to update VM Cluster
Keywords:
Status: CLOSED DUPLICATE of bug 1218528
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-restapi
Version: 3.5.0
Hardware: Unspecified
OS: Unspecified
urgent
urgent
Target Milestone: ---
: 3.5.0
Assignee: Roy Golan
QA Contact: Israel Pinto
URL:
Whiteboard: sla
Depends On:
Blocks: rhev35rcblocker rhev35gablocker
TreeView+ depends on / blocked
 
Reported: 2014-10-29 12:34 UTC by Israel Pinto
Modified: 2016-02-10 20:19 UTC (History)
15 users (show)

Fixed In Version:
Doc Type: Known Issue
Doc Text:
Using the Java SDK to fetch and change the cluster of a virtual machine sends the entire element to the API, including the outdated CPU profile of the previous cluster. Attempts to then update the virtual machine fails as CPU profile does not match with target cluster. The current workaround is to clear the cluster-specific fields when using the Java SDK to fetch and change the cluster of a virtual machine.
Clone Of:
Environment:
Last Closed: 2014-12-07 09:48:29 UTC
oVirt Team: SLA


Attachments (Terms of Use)
screenshot (204.77 KB, image/png)
2014-10-29 12:34 UTC, Israel Pinto
no flags Details


Links
System ID Priority Status Summary Last Updated
oVirt gerrit 35762 master ABANDONED restapi: Failed to update VM Cluster in SDK Never

Description Israel Pinto 2014-10-29 12:34:32 UTC
Created attachment 951762 [details]
screenshot

Description of problem:
While update VM cluster to other cluster with the same CPU family(SandyBridge)
getting "CanDoAction" failure.


Version-Release number of selected component (if applicable):
rhevm: 3.5.0-0.17.beta.el6ev

How reproducible:
1. Create 2 Cluster with CPU family:SandyBridge
2. Create VM on one cluster
3. Edit VM and select the second cluster

Actual results:
CanDoAction of action UpdateVm failed. Reasons:VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_CPU_PROFILE_NOT_MATCH_CLUSTER

Expected results:
VM with be updated with new cluster

Additional info:
See attached screenshot
From Engine log:

2014-10-29 11:44:18,425 INFO  [org.ovirt.engine.core.bll.ChangeVMClusterCommand] (ajp-/127.0.0.1:8702-12) [6b98a143] Running command: ChangeVMClusterCommand internal: false. Entities affected :  ID: 10f98c5d-fb97-4681-accc-c2d6619c3284 Type: VMAction group EDIT_VM_PROPERTIES with role type USER,  ID: 68c28727-87a1-4cd4-8e53-d368f080aee9 Type: VdsGroupsAction group CREATE_VM with role type USER
2014-10-29 11:44:18,665 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-12) [6b98a143] Correlation ID: 6b98a143, Call Stack: null, Custom Event ID: -1, Message: VM test configuration was updated by admin.
2014-10-29 11:44:18,936 INFO  [org.ovirt.engine.core.bll.UpdateVmCommand] (ajp-/127.0.0.1:8702-10) [1dbbfa3c] Lock Acquired to object EngineLock [exclusiveLocks= key: test value: VM_NAME
, sharedLocks= key: 10f98c5d-fb97-4681-accc-c2d6619c3284 value: VM
]
2014-10-29 11:44:18,975 WARN  [org.ovirt.engine.core.bll.UpdateVmCommand] (ajp-/127.0.0.1:8702-10) [1dbbfa3c] CanDoAction of action UpdateVm failed. Reasons:VAR__ACTION__UPDATE,VAR__TYPE__VM,ACTION_TYPE_CPU_PROFILE_NOT_MATCH_CLUSTER
2014-10-29 11:44:18,975 INFO  [org.ovirt.engine.core.bll.UpdateVmCommand] (ajp-/127.0.0.1:8702-10) [1dbbfa3c] Lock freed to object EngineLock [exclusiveLocks= key: test value: VM_NAME
, sharedLocks= key: 10f98c5d-fb97-4681-accc-c2d6619c3284 value: VM

Comment 2 Roy Golan 2014-11-19 08:52:51 UTC

*** This bug has been marked as a duplicate of bug 1142629 ***

Comment 3 Israel Pinto 2014-12-01 11:07:15 UTC
run automation test for vt12 (after fix).
The update vm cluster failed:
2014-11-30 18:06:11,754 - MainThread - api_utils - ERROR - Failed to update element:
	Status: 400
	Reason: Bad Request
	Detail: Cannot edit VM. CPU Profile doesn't match provided Cluster.
	Trace: org.ovirt.engine.sdk.web.HttpProxy.execute(Unknown Source)
	org.ovirt.engine.sdk.web.HttpProxyBroker.update(Unknown Source)
	org.ovirt.engine.sdk.decorators.VM.update(Unknown Source)

test in jenkins:
http://jenkins.qa.lab.tlv.redhat.com:8080/view/Compute/view/3.5-git/view/Virt/job/3.5-git-compute-virt-reg_vms-nfs/120/

Note:With UI the operation of update VM cluster succeed.

Comment 4 Michal Skrivanek 2014-12-01 16:47:15 UTC
so...UI works and this is only a REST problem.

also, workaround would be to remove the profile and re-add after the move? If so then why should this block ga?

Comment 5 Doron Fediuck 2014-12-01 17:05:51 UTC
This is related to the way Java SDK works.
In general the right way to handle it is fetch the VM, update the profile
to a relevant one (or null) and update it.

This is not a real blocker but we'll update the BZ soon.

Comment 6 Roy Golan 2014-12-02 08:05:46 UTC
just to elaborate:

the test case using sdk is doing this:

- fetching a VM object
- changeing its cluster
- sending it to the update

the problem is that the vm is sent with the OLD profile

so the REST api send update cluster cmd. it works. then send an update vm which fails. because the OLD profile is specified there. 

the api is behaving good imho. we can't make the api accept a wrong profile value and change it auto-magically to some working profile. that is surprising. APIs shouldn't be surprising or at least be as less surprising we can :)

same as pinning, if you try to change a cluster, you have some problems with cluster specific configurations.

Comment 7 Roy Golan 2014-12-02 08:10:52 UTC
Juan, Gilad comments?

Comment 8 Juan Hernández 2014-12-02 08:42:26 UTC
The solution in the proposed patch looks good to me.

Comment 9 Roy Golan 2014-12-02 17:09:53 UTC
see explanation in comment 6

Comment 10 Israel Pinto 2014-12-03 12:57:36 UTC
Since the Rest API change and it sets the 
profile while update the cluster.
This change break backward comparability for our customers.
I think this should be consider in this case.
And if it will not fixed this should be documented in release notes.

Comment 11 Andrew Burden 2014-12-08 04:49:09 UTC
Hey Roy,

I've updated the doctext for inclusion in Release Notes. Can you please review to ensure technical accuracy.

Cheers

Comment 12 Roy Golan 2014-12-08 07:12:03 UTC
(In reply to Andrew Burden from comment #11)
> Hey Roy,
> 
> I've updated the doctext for inclusion in Release Notes. Can you please
> review to ensure technical accuracy.
> 
> Cheers

seems good, thanks.

Comment 13 Roy Golan 2015-05-11 10:53:23 UTC
*** Bug 1218528 has been marked as a duplicate of this bug. ***

Comment 14 Roy Golan 2015-08-18 09:40:16 UTC

*** This bug has been marked as a duplicate of bug 1218528 ***


Note You need to log in before you can comment on or make changes to this bug.