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.
Maybe related, closed BZ1160846
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.
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.
(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.
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...
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.
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)
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
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.
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.
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.
Verified on rhevm-3.6.0.3-0.1.el6.noarch
its 3.5.z fix is verified see bug 1273037. Can you drop the 3.5.z ?
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.
According to verification status and target milestone this issue should be fixed in oVirt 3.6.1. Closing current release.