Description of problem: In CFME connected to 2 RHV Providers, that both have NFS data stores with the same name, rest api request will fail, as the actual NFS data store, CFME picks from the database, belong to the "Other" provider. Version-Release number of selected component (if applicable): CFME-5.7.1.3 RHV-4.0.7 Expected results: dataStore should probably be chosen by it's Id (like template is chosen by id), and not by it's name, as there are cases with data stores with the same name. Additional info: Even if the "Other" provider is removed, it's data stores remain in the Database.
This bug refer to automate Add disk operation as well.
https://github.com/ManageIQ/manageiq-providers-ovirt/pull/37
Pasting the content of https://bugzilla.redhat.com/show_bug.cgi?id=1450952#c4 here: The datastore-id aimed to solve ambiguous datastore selection, when a datastore is specified by its. A datastore name might appear more than once in one of the following scenarios: 1. The same datastore name is used by two different providers. 2. If provider was added to the ManageIQ, removed and added again - the same datastore is being kept twice. For the #1 case, when selecting a datastore by its name, the selection will be narrowed to the provider which is associated with the VM (the association is done base on the selected template). For the #2, when the provider is being removed, the associated provider ID is being deleted from the datastore entry, therefore there is no risk in ambiguous selection. Based on the above, there is no need to require specifying the datastore_id as part of the API. However #1 should be fixed as a resolution of this bug.
https://github.com/ManageIQ/manageiq/pull/15245
https://github.com/ManageIQ/manageiq-providers-ovirt/pull/42
New commit detected on ManageIQ/manageiq/master: https://github.com/ManageIQ/manageiq/commit/e9c07df17add1b64be791a703a99724e7fbe6b25 commit e9c07df17add1b64be791a703a99724e7fbe6b25 Author: Moti Asayag <masayag> AuthorDate: Sun May 14 14:11:51 2017 +0300 Commit: Moti Asayag <masayag> CommitDate: Thu Jun 8 07:15:15 2017 +0300 Select datastore by its association with the provider Datastores on the same setup may have the same name. However, there is an assumption that datastores names on the same provider are unique. The selection of datastore by its name should be narrow to the provider on which the vm is provisioned. https://bugzilla.redhat.com/show_bug.cgi?id=1427498 .../vm_or_template/operations/configuration.rb | 6 ++- .../operations/configuration_spec.rb | 59 ++++++++++++++++++++++ 2 files changed, 63 insertions(+), 2 deletions(-) create mode 100644 spec/models/vm_or_template/operations/configuration_spec.rb
New commit detected on ManageIQ/manageiq-providers-ovirt/master: https://github.com/ManageIQ/manageiq-providers-ovirt/commit/65710b3d00ad0161645fb10783530399d7ff06f5 commit 65710b3d00ad0161645fb10783530399d7ff06f5 Author: Moti Asayag <masayag> AuthorDate: Sun May 14 14:13:54 2017 +0300 Commit: Moti Asayag <masayag> CommitDate: Wed Jun 7 12:04:57 2017 +0300 Select datastore by its association with the provider Datastores on the same setup may have the same name. However, there is an assumption that datastores names on the same provider are unique. The selection of datastore by its name should be narrowed to the provider on which the vm is provisioned and has at least one host with write access. https://bugzilla.redhat.com/show_bug.cgi?id=1427498 .../redhat/infra_manager/provision/disk.rb | 27 ++++++++++----- .../redhat/infra_manager/provision/disk_spec.rb | 38 ++++++++++++++++++++++ .../infra_manager/provision/state_machine_spec.rb | 11 ++++++- 3 files changed, 67 insertions(+), 9 deletions(-)
Ilanit, I have verified that I can successfully provision VM when there are two providers with datastore that has the same name. I have ordered the provisioning from CFME UI. By REST API did you mean the communication between CFME and RHV or does the provision request must be done by user via REST API?
This bug refer to running VM provision in CFME. via REST API, and not via the CFME UI. In this Polarion test plan, you can find test cases, with examles on how to run it: RHEVM3/wiki/CFME/4_0_cfme_add_disk_in_provision_and_automate
Ok, so I tried to verify this bug, but I was unsuccessful. Mind you, I did not even set up two providers with datastore of the same name. I just wanted to verify that I can actually provision simple VM via REST. I sent POST request with this body: { "vm_fields": { "number_of_sockets": 1, "cores_per_socket": 1, "vm_name": "jzmeskal_rest_provision3", "vm_memory": "2048", "vlan": "ovirtmgmt" }, "template_fields": { "guid": "737cb966-5bfb-4a5b-ba7f-bc98c1fd0e00" }, "requester": { "user_name": "admin", "auto_approve": true, "owner_email": "jzmeskal" } } The request was created, but eventually it finished with this: "request_state": "finished", "message": "[EVM] VM [jzmeskal_rest_provision] Step [CheckProvisioned] Status [Error Creating VM] Message [[MiqException::MiqProvisionError]: Unable to find specified profile: <rhevm>] ", "status": "Error" So I made a second request where I changed "vm_fields" -> "vlan" from "ovirtmgmt" to "ovirtmgmt (ovirtmgmt)", becuase this is what's displayed in UI. However, the result ended in just the same way. For some reason, it seems that CFME tries to create VM with network I did not specify. Additional info: "ovirtmgmt" network actually exists on RHV provider. Template specified also exists. Those VMs I requested were actually provisioned on RHV end. Also, when I made the very same request via UI, it ended with this: "request_state": "finished", "message": "[EVM] VM [jzmeskal_rest_provision3] Provisioned Successfully", "status": "Ok"
Alona, Does comment #14 sounds familiar to a recent change done for vnic profile support via the rest api ?
(In reply to Moti Asayag from comment #15) > Alona, > > Does comment #14 sounds familiar to a recent change done for vnic profile > support via the rest api ? In the vlan filed you should specify the 'profile id'.
(In reply to Moti Asayag from comment #15) > Alona, > > Does comment #14 sounds familiar to a recent change done for vnic profile > support via the rest api ? In the vlan field you should specify the vnic profile id (you can query the value from oVirt's api).
(In reply to Alona Kaplan from comment #17) > (In reply to Moti Asayag from comment #15) > > Alona, > > > > Does comment #14 sounds familiar to a recent change done for vnic profile > > support via the rest api ? > > In the vlan field you should specify the vnic profile id (you can query the > value from oVirt's api). Link to the bug - https://bugzilla.redhat.com/1449157 Please notice the doc text has a description and an example of the vm provisioning.
Moti - what's the status here? Should it move back to on_qa?
(In reply to Oved Ourfali from comment #19) > Moti - what's the status here? > Should it move back to on_qa? Based on input from Alona, the code to handle network/vnic profile is already merged and can be tested with. Moving back to ON_QA to test with the required adjustments of the vlan field values.
Verified on: CFME 5.0.9.13 RHV 4.1.7.6 Verification steps: 1. Add two RHV providers to CFME, both have NFS datastore for VMs called "nfs_1" 2. Send REST request for VM provision specifying template ID belonging to the first provider 3. Do this few times and check that the VM is always provisioned on the first provider - the one having "your" template ID Additional info: I used POST request with the following data part: { "version" : "1.1", "template_fields" : { "guid": "dea30e46-17df-47b0-94c7-340b0be9027e" }, "vm_fields" : { "number_of_cpus" : 1, "vm_name" : "jzmeskal_rest_provision", "vm_memory" : "1024", "vlan" : "29776fcc-0e01-4226-a1b1-7cc568337746" }, "requester" : { "user_name" : "admin", "owner_first_name" : "John", "owner_last_name" : "Doe", "owner_email" : "jdoe", "auto_approve" : true }, "ems_custom_attributes" : { }, "miq_custom_attributes" : { } }