Bug 1019866 - edit vmpool right after prestarted vms configured starts more down pool VMs
edit vmpool right after prestarted vms configured starts more down pool VMs
Product: ovirt-engine
Classification: oVirt
Component: General (Show other bugs)
Unspecified Unspecified
unspecified Severity medium (vote)
: ---
: ---
Assigned To: nobody nobody
Depends On:
  Show dependency treegraph
Reported: 2013-10-16 10:20 EDT by Ilanit Stein
Modified: 2017-12-22 02:45 EST (History)
6 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Last Closed: 2017-08-21 04:37:02 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: Virt
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
rule-engine: ovirt‑4.2?
rule-engine: planning_ack?
rule-engine: devel_ack?
rule-engine: testing_ack?

Attachments (Terms of Use)

  None (edit)
Description Ilanit Stein 2013-10-16 10:20:12 EDT
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):

How reproducible:

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 09:01:25 EDT
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 09:11:14 EST
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 10:44:10 EDT
pushed out due to capacity reasons
Comment 5 Michal Skrivanek 2016-12-21 04:07:56 EST
The bug was not addressed in time for 4.1. Postponing to 4.2
Comment 6 Michal Skrivanek 2017-08-21 04:37:02 EDT
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.