Bug 1318212

Summary: It is not possible to set VM memory for next run.
Product: Red Hat Enterprise Virtualization Manager Reporter: Roman Hodain <rhodain>
Component: ovirt-engineAssignee: Arik <ahadas>
Status: CLOSED CURRENTRELEASE QA Contact: movciari
Severity: medium Docs Contact:
Priority: medium    
Version: 3.6.3CC: ahadas, bgraveno, gklein, juan.hernandez, lsurette, lsvaty, michal.skrivanek, pstehlik, rbalakri, Rhev-m-bugs, srevivo, ykaul
Target Milestone: ovirt-4.0.2   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1318261 (view as bug list) Environment:
Last Closed: 2016-07-26 10:49:19 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: Virt RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Bug Depends On:    
Bug Blocks: 1318261    

Description Roman Hodain 2016-03-16 09:52:12 UTC
Description of problem:
When increasing VM memory via rhevm-shell. The default behaviour is to hot-plug the memory. This does not have to be possible due to the compatibility version for instance.

Version-Release number of selected component (if applicable):
rhevm-cli-3.6.2.0-1.el6ev

How reproducible:
100%

Steps to Reproduce:
1. Start a VM on a cluster with 3.5 compatibility version.
2. Try to updte the memory: update vm ${VM_NAME} --memort ${MEMORY_SIZE}

Actual results:
The memory is not updated and engine reports an error in the engine.log

Expected results:
Add possibility to set the memory for next run.

Additional info:
This is a regression as this was possible in RHEV 3.5

A possible way to achieve is via curl:

curl -X PUT -H "Accept: application/xml" -H "Content-Type: application/xml" -u admin@internal:password --cacert /etc/pki/ovirt-engine/ca.pem -T data.xml 'https://rhevm36/ovirt-engine/api/vms/a774093d-fb09-4fb7-aff3-989d7c3755c1;next_run'

Comment 1 Juan Hernández 2016-03-16 11:30:24 UTC
There are two reasons why this doesn't work. First is that the "next_run" parameter isn't documented in the metadata of the API, thus from the point of view of the generators of the SDKs it doesn't exist.

The second reason is that currently the Python SDK doesn't support URL parameters in "update" operations. The CLI obtains the description of the API inspecting the Python SDK. Thus, from the point of view of the CLI, the "next_run" parameter won't exist even if it is added to the metadata of the API. To support it the generator of the SDK will need to be improved to support URL parameters (similar to bug 1311495), then the SDK will need to be regenerated.

I'm moving the bug to the ovirt-engine component, so that we can add "next_run" to the documentation. Then I will clone this bug for the Python SDK.

Comment 2 Yaniv Lavi 2016-05-09 11:00:04 UTC
oVirt 4.0 Alpha has been released, moving to oVirt 4.0 Beta target.

Comment 4 Arik 2016-05-22 15:59:26 UTC
Didn't you already add it to the metadata as part of 6fe49eb2 ?

Comment 7 Juan Hernández 2016-05-30 10:22:40 UTC
Patch 6fe49eb2 added the metadata for version 4 of the API, but in order to support it in the CLI it needs to be backported to version 3 of the engine, as the CLI uses version 3 of the Python SDK, and version 3 of the Python SDK is generated from the metadata provided by version 3 of the engine. So, if we want to fix this, the bug needs to be re-targeted to version 3 of the engine. Once that is merged and released we can regenerate version 3 of the Python SDK.

Comment 8 Michal Skrivanek 2016-07-20 12:15:56 UTC
Based on comment #7 this is fixed in the SDK version 4. Since CLI is using version 3 it's not reflected in the CLI.
This is deemed enough, in case someone needs this parameter then we suggest to use python SDK and 2-3 lines to write it using APIv4

Comment 10 Lukas Svaty 2016-07-26 10:49:19 UTC
This bug was fixed and is slated to be in the upcoming version. As we
are focusing our testing at this phase on severe bugs, this bug was
closed without going through its verification step. If you think this
bug should be verified by QE, please set its severity to high and move
it back to ON_QA