Bug 1262293

Summary: Creating a VM with Foreman fails if cluster has more than one CPU profile
Product: [oVirt] ovirt-engine Reporter: Daniel Helgenberger <daniel.helgenberger>
Component: RestAPIAssignee: Martin Sivák <msivak>
Status: CLOSED CURRENTRELEASE QA Contact: Artyom <alukiano>
Severity: high Docs Contact:
Priority: unspecified    
Version: 3.5.4CC: bugs, gklein, mavital, mgoldboi, msivak, rgolan, sbonazzo, ylavi
Target Milestone: ovirt-3.6.1Keywords: Regression, Triaged
Target Release: 3.6.0.3Flags: ylavi: ovirt-3.6.z+
rule-engine: blocker+
mgoldboi: planning_ack+
rgolan: devel_ack+
mavital: testing_ack+
Hardware: Unspecified   
OS: Unspecified   
Whiteboard: sla
Fixed In Version: 3.6.0-16 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-12-16 12:19:48 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: SLA RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:
Attachments:
Description Flags
sample engine.log none

Description Daniel Helgenberger 2015-09-11 10:58:18 UTC
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 10:58:58 UTC
Maybe related, closed BZ1160846

Comment 2 Red Hat Bugzilla Rules Engine 2015-09-22 07:44:00 UTC
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 07:33:38 UTC
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 10:30:24 UTC
(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 10:38:37 UTC
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 08:33:47 UTC
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 14:25:25 UTC
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 12:26:41 UTC
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 15:58:58 UTC
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 15:59:03 UTC
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 15:59:03 UTC
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 15:59:03 UTC
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 09:14:05 UTC
Verified on rhevm-3.6.0.3-0.1.el6.noarch

Comment 16 Roy Golan 2015-11-16 08:16:27 UTC
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 11:55:08 UTC
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 11:55:08 UTC
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 11:55:08 UTC
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 12:19:48 UTC
According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.