Bug 1019866

Summary:	edit vmpool right after prestarted vms configured starts more down pool VMs
Product:	[oVirt] ovirt-engine	Reporter:	Ilanit Stein <istein>
Component:	General	Assignee:	Nobody <nobody>
Status:	CLOSED DEFERRED	QA Contact:
Severity:	medium	Docs Contact:
Priority:	unspecified
Version:	---	CC:	bugs, lpeer, michal.skrivanek, rbalakri, Rhev-m-bugs, srevivo
Target Milestone:	---	Flags:	rule-engine: ovirt-4.2? rule-engine: planning_ack? rule-engine: devel_ack? rule-engine: testing_ack?
Target Release:	---
Hardware:	Unspecified
OS:	Unspecified
Whiteboard:
Fixed In Version:		Doc Type:	Bug Fix
Doc Text:		Story Points:	---
Clone Of:		Environment:
Last Closed:	2017-08-21 08:37:02 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:

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