Bug 1019866 - edit vmpool right after prestarted vms configured starts more down pool VMs
Summary: edit vmpool right after prestarted vms configured starts more down pool VMs
Keywords:
Status: CLOSED DEFERRED
Alias: None
Product: ovirt-engine
Classification: oVirt
Component: General
Version: ---
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: ---
Assignee: Nobody
QA Contact:
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2013-10-16 14:20 UTC by Ilanit Stein
Modified: 2017-12-22 07:45 UTC (History)
6 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-21 08:37:02 UTC
oVirt Team: Virt
Embargoed:
rule-engine: ovirt-4.2?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

Description Ilanit Stein 2013-10-16 14:20:12 UTC 
Description of problem:

After edit vmpool to have some prestarted VM, edit vmpool again (while started vms still in powering up state) and press OK starts more "down VMs in the pool.
 
Version-Release number of selected component (if applicable):
IS18

How reproducible:
100%

Steps to Reproduce:
1. create a vmpool 
2. edit vmpool and configure some number "prestarted" vms. 
3. Before the started vms came up (while still in powering up) edit vmpool, and press OK.
additional down VMs will be started.

Expected results:
The "prestart" action should check also if there are also VMs in powering up,
and not start more down VMs in the pool.
Comment 2 Michal Skrivanek 2014-08-22 13:01:25 UTC 
this bug won't fit into 3.5 release and is being deferred to a later release. If you deeply care about this bug and deserves to be re-evaluated please let me know
Comment 3 Red Hat Bugzilla Rules Engine 2015-11-16 14:11:14 UTC 
This bug is flagged for 3.6, yet the milestone is for 4.0 version, therefore the milestone has been reset.
Please set the correct milestone or add the flag.
Comment 4 Michal Skrivanek 2016-04-22 14:44:10 UTC 
pushed out due to capacity reasons
Comment 5 Michal Skrivanek 2016-12-21 09:07:56 UTC 
The bug was not addressed in time for 4.1. Postponing to 4.2
Comment 6 Michal Skrivanek 2017-08-21 08:37:02 UTC 
we didn't fix this for almost 4 years, unlikely to happen
Note You need to log in before you can comment on or make changes to this bug.