Created attachment 1296083 [details] evm log Description of problem: [VM Provision] - Destination 'Cluster' should be required in order to submit VM provision. When trying to provision VM in cfme 5.8.1, it is allowed to submit the request without specifing the destination cluster, but in the end we failing with error: [2017-07-11T02:02:15.719206 #2959:125e210] ERROR -- : Q-task_id([miq_provision_1]) <AutomationEngine> <AEMethod update_provision_status> VM Provision Error: [EVM] VM [test_cfme_vm1] Step [CheckProvisione d] Status [Error Creating VM] Message [[MiqException::MiqProvisionError]: Destination cluster not provided] Currently the required feilds for submit request are: 'Request/E-Main' 'Catalog/VM Name' 'Network'/vLan' Destination 'Cluster' should be required as well if VM provision will fail in the end because of: 'Destination cluster not provided' Version-Release number of selected component (if applicable): 5.8.1.0.20170623170756_3ed4411 How reproducible: 100% Steps to Reproduce: 1. Lifecycle > Open provision vm dialog 2. Select a source template 3. Provide e-mail, network and VM name and press 'Submit' Actual results: VM provision has failed - VM Provision Error: [EVM] VM [test_cfme_vm1] Step [CheckProvisioned] Status [Error Creating VM] Message [[MiqException::MiqProvisionError]: Destination cluster not provided Expected results: Make destination 'Cluster' required for submit
The problem starts with the current behavior, if the Infra rhv-m provider has a DC with 2 active clusters, which means a running host in each cluster in the DC, this bug will happen, because in case of two clusters in the DC which have a running host each, the destination cluster will be set to default <none> by cfme on the provision VMs flow. - If the destination DC, has only one active cluster, the only cluster in the DC which have a running host, then the active cluster will be set by cfme as the default destination cluster. - So, because of this current behaviour, if i have a DC with 2 active clusters in the destination, the cluster will be set to <none> and because there is no requirement for it, I'm able to do submit, but then fail to provision VM.
Oved - Can someone on your team take a look. I am actually surprised that we have not had this field marked required since it is the only placement field that the backend checks for RHV. Back-end check: https://github.com/ManageIQ/manageiq-providers-ovirt/blob/master/app/models/manageiq/providers/redhat/infra_manager/provision/placement.rb#L7 Also want to point out that if we mark this field as required the field will also need a "required_method" property so it handles the "Choose Automatically" option. :required_method: :validate_placement Example VMWare field: https://github.com/ManageIQ/manageiq/blob/master/product/dialogs/miq_dialogs/miq_provision_vmware_dialogs_template.yaml#L447
https://github.com/ManageIQ/manageiq/pull/16281
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/21180e26d4a0a7f682ba95d8c845a3c5e3d46efa commit 21180e26d4a0a7f682ba95d8c845a3c5e3d46efa Author: Moti Asayag <masayag> AuthorDate: Tue Oct 24 16:33:37 2017 +0300 Commit: Moti Asayag <masayag> CommitDate: Tue Oct 24 17:03:41 2017 +0300 Require cluster for RVH VM provision In order to provision VM on RHV, when not selecting the auto-placement, user should specify the destination cluster as well. The PR enforces the selection of the destination cluster. https://bugzilla.redhat.com/show_bug.cgi?id=1469364 .../dialogs/miq_dialogs/miq_provision_redhat_dialogs_template.yaml | 4 +++- 1 file changed, 3 insertions(+), 1 deletion(-)
Verified on: CFME 5.9.0.4 RHV 4.1.7.4 Verification steps: I have followed steps to reproduce. VM now cannot be provisioned w/o cluster, so the mentioned error won't occur.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHSA-2018:0380