Bug 1258380 - [VM Pools][REST-API] setting prestarted vms upon vmPool creation is blocked in UI but not in API
Summary: [VM Pools][REST-API] setting prestarted vms upon vmPool creation is blocked i...
Keywords:
Status: CLOSED CURRENTRELEASE
Alias: None
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine
Version: 3.6.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ovirt-3.6.1
: 3.6.0
Assignee: Shmuel Melamud
QA Contact: sefi litmanovich
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2015-08-31 09:02 UTC by sefi litmanovich
Modified: 2016-04-20 01:30 UTC (History)
9 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2016-04-20 01:30:41 UTC
oVirt Team: Virt
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
oVirt gerrit 46703 0 master MERGED webadmin: Allow to set prestarted VMs for a new VM pool Never
oVirt gerrit 47372 0 ovirt-engine-3.6 MERGED webadmin: Allow to set prestarted VMs for a new VM pool Never

Description sefi litmanovich 2015-08-31 09:02:29 UTC
Description of problem:

In the webadmin when adding a new vm pool the prestarted vms option is blocked and open only after creation when editing the pool.
In API you can create a vm pool and set the number of prestarted_vms from the start:

POST

<vmpool>
<name>test</name>
<size>3</size>
<cluster href= "/ovirt-engine/api/clusters/{clusted_id}" id="{clusted_id}"/>
<template href= "/ovirt-engine/api/templates/{template_id}" id="{template_id}"/>
<prestarted_vms>2</prestarted_vms>
<max_user_vms>1</max_user_vms>
</vmpool>

when creating the pool this way, the 2 prestarted vms won't start up also after some waiting time, only if you edit the pool again will it invoke the start up of the vms. this might relate to this old bz: https://bugzilla.redhat.com/show_bug.cgi?id=1046421

Version-Release number of selected component (if applicable):

rhevm-3.6.0-0.12.master.el6.noarch

How reproducible:

always

Actual results:

Vm pool is created with the prestarted_vms value set but no vms actually starts.

Expected results:

either fail the POST call with the prestarted_vms tag with a relevant error message, or allow creation with prestarted_vms and make sure that they start after creation.

Comment 1 sefi litmanovich 2015-08-31 09:11:40 UTC
Small correction to my description:

when creating the pool with prestarted_vms through API, the vms will start after 5 minutes (or any set value of VmPoolMonitorIntervalInMinutes paramter).

Comment 2 Omer Frenkel 2015-09-01 08:49:13 UTC
Gil, why this is High severity?
its just a mismatch between rest and ui, which happens many times (sometimes even on purpose), there is no failure in this scenario, please note that depends on the solution for bug 1046421 we might allow this in the ui as well

Comment 3 Gil Klein 2015-09-01 09:47:23 UTC
(In reply to Omer Frenkel from comment #2)
> Gil, why this is High severity?
> its just a mismatch between rest and ui, which happens many times (sometimes
> even on purpose), there is no failure in this scenario, please note that
> depends on the solution for bug 1046421 we might allow this in the ui as well
Ok, moved to medium

Comment 4 Shmuel Melamud 2015-09-20 13:33:50 UTC
I don't see any problem here. Setting prestarted_vms on pool creation works - the VMs are started after 5 minutes. VM_POOL lock now blocks editing of VM pool parameters until all VMs are created, so bug 1046421 is irrelevant. I think, setting number of prestarted VMs in the UI also can be enabled.

Comment 5 Omer Frenkel 2015-09-20 17:54:05 UTC
great, thanks!
so lets enable in UI as well.

Comment 7 sefi litmanovich 2015-11-26 13:17:09 UTC
Verified with rhevm-3.6.1-0.2.el6.noarch.

Created a vm pool and set prestarted vms on creation (both from UI (new option) and REST api).
Both cases the pool was created successfully and the amount of defined prestarted vms were started after {VmPoolMonitorIntervalInMinutes} minutes.


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