Bug 1262293 - Creating a VM with Foreman fails if cluster has more than one CPU profile
Creating a VM with Foreman fails if cluster has more than one CPU profile
Status: CLOSED CURRENTRELEASE
Product: ovirt-engine
Classification: oVirt
Component: RestAPI (Show other bugs)
3.5.4
Unspecified Unspecified
unspecified Severity high (vote)
: ovirt-3.6.1
: 3.6.0.3
Assigned To: Martin Sivák
Artyom
sla
: Regression, Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2015-09-11 06:58 EDT by Daniel Helgenberger
Modified: 2016-02-10 14:20 EST (History)
8 users (show)

See Also:
Fixed In Version: 3.6.0-16
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-12-16 07:19:48 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: SLA
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---
ylavi: ovirt‑3.6.z+
rule-engine: blocker+
mgoldboi: planning_ack+
rgolan: devel_ack+
mavital: testing_ack+


Attachments (Terms of Use)
sample engine.log (928 bytes, text/plain)
2015-09-11 06:58 EDT, Daniel Helgenberger
no flags Details


External Trackers
Tracker ID Priority Status Summary Last Updated
oVirt gerrit 46658 master MERGED Select the first CPU profile when multiple are available Never
oVirt gerrit 47076 ovirt-engine-3.6 MERGED Select the first CPU profile when multiple are available Never
oVirt gerrit 47116 refs/tags/ovirt-engine-3.6.0 ABANDONED Select the first CPU profile when multiple are available Never
oVirt gerrit 47228 ovirt-engine-3.6.0 MERGED Select the first CPU profile when multiple are available Never

  None (edit)
Description Daniel Helgenberger 2015-09-11 06:58:18 EDT
Created attachment 1072535 [details]
sample engine.log

Description of problem:
When adding a host using foremen ovirt compute prov., creating the VM fails with 'Error: action type cpu profile empty' if more then one cpu profile is defined in the cluster.

Version-Release number of selected component (if applicable):
ovirt engine 3.5.0 - 3.5.4
foreman 1.8.0 - 1.9.0

How reproducible:
always

Steps to Reproduce:
1. Set up foreman compute provisoniong for ovirt
2. Add a second cpu profile to cluster
3. Provision a VM using foreman in that cluster using any template

optional
4. Observe error
5. Remove the profile created in step (2)
6. Redo step (3); witch works now

Actual results:
Error: action type cpu profile empty

Expected results:
'Default' cpu profile is used if none is defined

Additional info:
Even when using templates witch have a cpu provfile defined the action fails.
Comment 1 Daniel Helgenberger 2015-09-11 06:58:58 EDT
Maybe related, closed BZ1160846
Comment 2 Red Hat Bugzilla Rules Engine 2015-09-22 03:44:00 EDT
This bug report has Keywords: Regression or TestBlocker.
Since no regressions or test blockers are allowed between releases, it is also being identified as a blocker for this release. Please resolve ASAP.
Comment 3 Roy Golan 2015-09-24 03:33:38 EDT
this needs an RFE to change the behaviour and handle default profiles.

meanwhile, for cpu profiles only,  the fix should pick the first from the list to remove the regression.
Comment 4 Daniel Helgenberger 2015-10-08 06:30:24 EDT
(In reply to Roy Golan from comment #3)
> this needs an RFE to change the behaviour and handle default profiles.
> 
> meanwhile, for cpu profiles only,  the fix should pick the first from the
> list to remove the regression.

Good call, pls see BZ1269834.
Comment 5 Daniel Helgenberger 2015-10-08 06:38:37 EDT
Roy, I looked at the merge and it seems to me it only changes the api call validation? Think this could be easily backported to 3.5, at least for me...
Comment 6 Red Hat Bugzilla Rules Engine 2015-10-18 04:33:47 EDT
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Comment 7 Eyal Edri 2015-11-01 09:25:25 EST
this bug has both 3.5.z & 3.6.0 flags, in bugzilla lang it means its a clone candidate from 3.6.0 to 3.5.z meaning it's pending a clone and wasn't fixed for 3.5.z.

if this isn't the case, please fix flags accordingly,
if it is the case, then please clone the bugs to 3.5.7 (3.5.6 was built already)
Comment 8 Red Hat Bugzilla Rules Engine 2015-11-02 07:26:41 EST
Bug tickets that are moved to testing must have target release set to make sure tester knows what to test. Please set the correct target release before moving to ON_QA.
Comment 9 Martin Sivák 2015-11-03 10:58:58 EST
Please teach your script to interpret Fixed in version or make sure the infra group's scripts know how to set the required fields. The builds are out of my control and this rule creates unnecessary noise.

I see that the infra automation set the following immediately after a build:

Status: MODIFIED → ON_QA
Fixed In Version: 3.6.0-16
Build ID: 3.6.0-16
Comment 10 Red Hat Bugzilla Rules Engine 2015-11-03 10:59:03 EST
This bug is marked for z-stream, yet the milestone is for a major version, therefore the milestone has been reset.
Please set the correct milestone or drop the z stream flag.
Comment 11 Red Hat Bugzilla Rules Engine 2015-11-03 10:59:03 EST
Fixed bug tickets must have target milestone set prior to fixing them. Please set the correct milestone and move the bugs back to the previous status after this is corrected.
Comment 12 Red Hat Bugzilla Rules Engine 2015-11-03 10:59:03 EST
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 13 Artyom 2015-11-09 04:14:05 EST
Verified on rhevm-3.6.0.3-0.1.el6.noarch
Comment 16 Roy Golan 2015-11-16 03:16:27 EST
its 3.5.z fix is verified see bug 1273037. Can you drop the 3.5.z ?
Comment 17 Red Hat Bugzilla Rules Engine 2015-11-16 06:55:08 EST
This bug is not marked for z-stream, yet the milestone is for a z-stream version, therefore the milestone has been reset.
Please set the correct milestone or add the z-stream flag.
Comment 18 Red Hat Bugzilla Rules Engine 2015-11-16 06:55:08 EST
Fixed bug tickets must have target milestone set prior to fixing them. Please set the correct milestone and move the bugs back to the previous status after this is corrected.
Comment 19 Red Hat Bugzilla Rules Engine 2015-11-16 06:55:08 EST
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
Comment 20 Sandro Bonazzola 2015-12-16 07:19:48 EST
According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.

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