Bug 1310842 - Service : Service catalog requests randomly fails with error in logs
Service : Service catalog requests randomly fails with error in logs
Status: CLOSED ERRATA
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Provisioning (Show other bugs)
5.5.0
Unspecified Unspecified
high Severity high
: GA
: 5.6.0
Assigned To: Bill Wei
Shveta
service:catalog:provision
: ZStream
Depends On:
Blocks: 1313067
  Show dependency treegraph
 
Reported: 2016-02-22 13:53 EST by Shveta
Modified: 2016-06-29 11:38 EDT (History)
8 users (show)

See Also:
Fixed In Version: 5.6.0.0
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 1313067 1370085 (view as bug list)
Environment:
Last Closed: 2016-06-29 11:38:43 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
logs (4.83 MB, text/plain)
2016-02-22 13:53 EST, Shveta
no flags Details

  None (edit)
Description Shveta 2016-02-22 13:53:53 EST
Created attachment 1129464 [details]
logs

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:
Comment 2 Shveta 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')]>
Comment 3 Greg McCullough 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.
Comment 4 Shveta 2016-02-22 15:12:16 EST
Yes Vmware provisioning request.
Same error was noticed while a direct provision (From Infrastructure- Provision Vm's)
Comment 5 Greg McCullough 2016-02-23 08:10:57 EST
Do you have an appliance we can connect to and see this issue?
Comment 6 Shveta 2016-02-23 12:42:04 EST
https://10.8.199.203
Comment 7 Greg McCullough 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.
Comment 8 Shveta 2016-02-23 19:46:12 EST
New environment https://10.8.199.55
Comment 9 Greg McCullough 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.
Comment 12 CFME Bot 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@redhat.com>
AuthorDate: Mon Mar 7 22:37:02 2016 -0500
Commit:     Bill Wei <bilwei@redhat.com>
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(-)
Comment 14 CFME Bot 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@redhat.com>
AuthorDate: Fri Apr 15 10:36:07 2016 -0400
Commit:     Greg McCullough <gmccullo@redhat.com>
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(-)
Comment 15 CFME Bot 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@redhat.com>
AuthorDate: Mon Mar 7 22:37:02 2016 -0500
Commit:     Bill Wei <bilwei@redhat.com>
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
Comment 16 Shveta 2016-04-16 20:04:39 EDT
Fixed.
verified in 5.6.0.1-beta2.20160413141124_e25ac0e
Comment 18 errata-xmlrpc 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

Note You need to log in before you can comment on or make changes to this bug.