Bug 1370085

Request for backport 

+++ This bug was initially created as a clone of Bug #1310842 +++

Description of problem:


Version-Release number of selected component (if applicable):


How reproducible:


Steps to Reproduce:
1. Randomly service catalog requests fails with error mentioned in logs.
2.
3.

Actual results:


Expected results:


Additional info:

--- Additional comment from Shveta on 2016-02-22 14:01:26 EST ---

---] I, [2016-02-22T13:26:49.306592 #2995:130734c]  INFO -- : Q-task_id([service_template_provision_task_1]) <AEMethod check_provisioned> 	user: #<MiqAeMethodService::MiqAeServiceUser:0x000000024da1a0>
[----] I, [2016-02-22T13:26:49.309769 #2995:130734c]  INFO -- : Q-task_id([service_template_provision_task_1]) <AEMethod check_provisioned> 	user_id: 1
[----] I, [2016-02-22T13:26:49.312902 #2995:130734c]  INFO -- : Q-task_id([service_template_provision_task_1]) <AEMethod check_provisioned> 	vmdb_object_type: service_template_provision_task
[----] I, [2016-02-22T13:26:49.315225 #2995:12f8b1c]  INFO -- : Q-task_id([service_template_provision_task_1]) <AEMethod check_provisioned> ===========================================
[----] I, [2016-02-22T13:26:49.329320 #2995:12f8b1c]  INFO -- : Q-task_id([service_template_provision_task_1]) <AEMethod check_provisioned> Service ProvisionCheck returned <error> for state <finished> and status <Error>
[----] I, [2016-02-22T13:26:49.375873 #2995:881990]  INFO -- : Q-task_id([service_template_provision_task_1]) <AEMethod [/ManageIQ/Service/Provisioning/StateMachines/Methods/check_provisioned]> Ending
[----] I, [2016-02-22T13:26:49.376188 #2995:881990]  INFO -- : Q-task_id([service_template_provision_task_1]) Method exited with rc=MIQ_OK
[----] I, [2016-02-22T13:26:49.377215 #2995:881990]  INFO -- : Q-task_id([service_template_provision_task_1]) Followed  Relationship [miqaedb:/Service/Provisioning/StateMachines/Methods/CheckProvisioned#create]
[----] I, [2016-02-22T13:26:49.377562 #2995:881990]  INFO -- : Q-task_id([service_template_provision_task_1]) Processed  State=[checkprovisioned] with Result=[error]
[----] W, [2016-02-22T13:26:49.377933 #2995:881990]  WARN -- : Q-task_id([service_template_provision_task_1]) Error in State=[checkprovisioned]
[----] I, [2016-02-22T13:26:49.378507 #2995:881990]  INFO -- : Q-task_id([service_template_provision_task_1]) In State=[checkprovisioned], invoking [on_error] method=[update_serviceprovision_status(status => 'A specified parameter was not correct. 
spec.location.folder')]
[----] E, [2016-02-22T13:26:49.379033 #2995:881990] ERROR -- : Q-task_id([service_template_provision_task_1]) State=<checkprovisioned> running on_error raised exception: <invalid method calling syntax: [update_serviceprovision_status(status => 'A specified parameter was not correct. 
spec.location.folder')]>

--- Additional comment from Greg McCullough on 2016-02-22 14:32:11 EST ---

This looks like a VMware provisioning error being raised up from the service.  Can you provider more details about the Service configuration?

If possible can you try a direct provision request instead for the same thing instead of going through services.

--- Additional comment from Shveta on 2016-02-22 15:12:16 EST ---

Yes Vmware provisioning request.
Same error was noticed while a direct provision (From Infrastructure- Provision Vm's)

--- Additional comment from Greg McCullough on 2016-02-23 08:10:57 EST ---

Do you have an appliance we can connect to and see this issue?

--- Additional comment from Shveta on 2016-02-23 12:42:04 EST ---

https://10.8.199.203

--- Additional comment from Greg McCullough on 2016-02-23 18:43:37 EST ---

It looks like that appliance has been reset with a new provider.  The provider used to create the issue has been removed and now the template is an orphaned resources.  Do you have an environment where we can recreate this issue?

I tried provisioning a VMware template to the "Discovered virtual machine" on a development VMware environment which matches the folder being used you your failed run and it was successful.

We need an environment were we can consistently recreate this issue.

--- Additional comment from Shveta on 2016-02-23 19:46:12 EST ---

New environment https://10.8.199.55

--- Additional comment from Greg McCullough on 2016-02-29 11:11:56 EST ---

The issue here is that VMware requires a folder to be passed as part of the VM clone task.  This folder, if not selected in the dialog, uses the source template as the starting point for the folder.

Vmware v4 did not support provisioning a template to a different data-center, that changed with v5.  The CloudForms UI has always shown that a template can be deployed across data-centers.

The fix is that provisioning should always select a folder that corresponds to the destination data-center folder and not the source.  See here:
https://github.com/ManageIQ/manageiq/blob/master/app/models/manageiq/providers/vmware/infra_manager/provision/cloning.rb#L40

This same logic (selecting folder from source data-center) is duplicated in the RedHat domain and should be removed.

There is a work-around in the ManageIQ domain which could be removed when the model is corrected.

--- Additional comment from Greg McCullough on 2016-02-29 11:44:42 EST ---

The ManageIQ domain logic is here:
https://github.com/ManageIQ/manageiq/blob/master/db/fixtures/ae_datastore/ManageIQ/Infrastructure/VM/Provisioning/Placement.class/__methods__/vmware_best_fit_least_utilized.rb#L8

--- Additional comment from CFME Bot on 2016-03-09 12:20:45 EST ---

https://github.com/ManageIQ/manageiq/pull/7150

--- Additional comment from CFME Bot on 2016-03-16 09:10:37 EDT ---

New commit detected on ManageIQ/manageiq/master:
https://github.com/ManageIQ/manageiq/commit/c755248c4150ab5053c50b19e9b72303ae0f2511

commit c755248c4150ab5053c50b19e9b72303ae0f2511
Author:     Bill Wei <bilwei>
AuthorDate: Mon Mar 7 22:37:02 2016 -0500
Commit:     Bill Wei <bilwei>
CommitDate: Mon Mar 14 16:37:28 2016 -0400

    Decide default destination folder for cloning
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1310842

 .../vmware/infra_manager/provision/cloning.rb      | 35 ++++++++----
 .../__methods__/vmware_best_fit_least_utilized.rb  | 23 +-------
 .../vmware_best_fit_least_utilized_spec.rb         | 63 +++++++++++++---------
 .../vmware/infra_manager/provision_spec.rb         | 41 +++++++++++++-
 4 files changed, 103 insertions(+), 59 deletions(-)

--- Additional comment from CFME Bot on 2016-03-17 17:06:38 EDT ---

https://github.com/ManageIQ/manageiq/pull/7338

--- Additional comment from CFME Bot on 2016-04-15 11:24:20 EDT ---

New commit detected on cfme/5.5.z:
https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=39ae339e5fd0dc5df981e9840e39d6aac32ea71e

commit 39ae339e5fd0dc5df981e9840e39d6aac32ea71e
Merge: a627f40 0327cae
Author:     Greg McCullough <gmccullo>
AuthorDate: Fri Apr 15 10:36:07 2016 -0400
Commit:     Greg McCullough <gmccullo>
CommitDate: Fri Apr 15 10:36:07 2016 -0400

    Merge branch '5.5.z_vmware_placement' into '5.5.z'
    
    Decide default destination folder for cloning
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1310842
    
    5.5.z https://bugzilla.redhat.com/show_bug.cgi?id=1313067
    
    Cherry-pick is not clean. There is a conflict with provision_spec. It is a minor coding style difference. The solution is to accept the existing one in 5.5.z.
    
    See merge request !866

 .../vmware/infra_manager/provision/cloning.rb      |   35 +-
 .../__methods__/vmware_best_fit_least_utilized.rb  |   23 +-
 .../vmware_best_fit_least_utilized_spec.rb         |   63 +-
 spec/examples.txt                                  | 3450 ++++++++++++++++++++
 .../vmware/infra_manager/provision_spec.rb         |   39 +
 5 files changed, 3552 insertions(+), 58 deletions(-)

--- Additional comment from CFME Bot on 2016-04-15 11:24:24 EDT ---

New commit detected on cfme/5.5.z:
https://code.engineering.redhat.com/gerrit/gitweb?p=cfme.git;a=commitdiff;h=0327cae4dcbcfd50c4749c4c6df2791fb39dd9bf

commit 0327cae4dcbcfd50c4749c4c6df2791fb39dd9bf
Author:     Bill Wei <bilwei>
AuthorDate: Mon Mar 7 22:37:02 2016 -0500
Commit:     Bill Wei <bilwei>
CommitDate: Mon Mar 21 12:13:55 2016 -0400

    Decide default destination folder for cloning
    
    https://bugzilla.redhat.com/show_bug.cgi?id=1310842

 .../vmware/infra_manager/provision/cloning.rb      |   35 +-
 .../__methods__/vmware_best_fit_least_utilized.rb  |   23 +-
 .../vmware_best_fit_least_utilized_spec.rb         |   63 +-
 spec/examples.txt                                  | 3450 ++++++++++++++++++++
 .../vmware/infra_manager/provision_spec.rb         |   39 +
 5 files changed, 3552 insertions(+), 58 deletions(-)
 create mode 100644 spec/examples.txt

--- Additional comment from Shveta on 2016-04-16 20:04:39 EDT ---

Fixed.
verified in 5.6.0.1-beta2.20160413141124_e25ac0e

--- Additional comment from errata-xmlrpc on 2016-06-29 11:38:43 EDT ---

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/RHBA-2016:1348