Bug 1601583 - Azure provider refresh fails with "Timed out connecting to server"
Summary: Azure provider refresh fails with "Timed out connecting to server"
Keywords:
Status: CLOSED DUPLICATE of bug 1600968
Alias: None
Product: Red Hat CloudForms Management Engine
Classification: Red Hat
Component: Providers
Version: 5.10.0
Hardware: Unspecified
OS: Unspecified
medium
high
Target Milestone: GA
: 5.10.0
Assignee: Daniel Berger
QA Contact: Brandon Squizzato
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2018-07-16 18:49 UTC by Brandon Squizzato
Modified: 2018-07-17 13:50 UTC (History)
5 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2018-07-17 13:50:56 UTC
Category: ---
Cloudforms Team: Azure
Target Upstream Version:
Embargoed:
bsquizza: automate_bug-


Attachments (Terms of Use)

Description Brandon Squizzato 2018-07-16 18:49:51 UTC
Description of problem:

When refreshing an Azure provider, the refresh fails with this error:
[] Timed out connecting to server (cause: Timed out connecting to server) 

On the appliance in /var/www/miq/vmdb/log/azure.log, you see that the appliance is able to connect to the azure cloud and is successfully sending requests/receiving responses.

A traceback in /var/www/miq/vmdb/log/evm.log shows that the failure is occurring in the 'get_template' method of template_deployment_service.rb in azure-armrest:

[----] E, [2018-07-16T14:20:35.725529 #35053:c9cf84] ERROR -- : MIQ(ManageIQ::Providers::Azure::CloudManager::Refresher#refresh) EMS: [Azure], id: [5] Refresh failed
[----] E, [2018-07-16T14:20:35.725887 #35053:c9cf84] ERROR -- : [Azure::Armrest::OpenTimeoutException]: Timed out connecting to server  Method:[block in method_missing]
[----] E, [2018-07-16T14:20:35.726063 #35053:c9cf84] ERROR -- : /opt/rh/cfme-gemset/gems/azure-armrest-0.9.12/lib/azure/armrest/armrest_service.rb:277:in `raise_api_exception'
/opt/rh/cfme-gemset/gems/azure-armrest-0.9.12/lib/azure/armrest/armrest_service.rb:227:in `rescue in rest_execute'
/opt/rh/cfme-gemset/gems/azure-armrest-0.9.12/lib/azure/armrest/armrest_service.rb:208:in `rest_execute'
/opt/rh/cfme-gemset/gems/azure-armrest-0.9.12/lib/azure/armrest/armrest_service.rb:300:in `rest_execute'
/opt/rh/cfme-gemset/gems/azure-armrest-0.9.12/lib/azure/armrest/armrest_service.rb:316:in `rest_post'
/opt/rh/cfme-gemset/gems/azure-armrest-0.9.12/lib/azure/armrest/template_deployment_service.rb:47:in `get_template'
/opt/rh/cfme-gemset/bundler/gems/cfme-providers-azure-d8e686ba75e3/app/models/manageiq/providers/azure/cloud_manager/refresh_parser.rb:450:in `direct_stack_template'
/opt/rh/cfme-gemset/bundler/gems/cfme-providers-azure-d8e686ba75e3/app/models/manageiq/providers/azure/cloud_manager/refresh_parser.rb:446:in `stack_template_hash'


Back in azure.log, searching for requests sent to 'deployments' URLs, we can see a request to export a deployment template never received a response:
[----] W, [2018-07-16T14:19:35.551651 #35053:c9cf84]  WARN -- : RestClient.post "https://management.azure.com/subscriptions/c9e72ccc-b20e-48bd-a0c8-879c6dbcbfbb/resourceGroups/bsquizz-resource-grp/providers/Microsoft.Resources/deployments/vm_deploy_ANH6SwtHoaQImMKopvQUy95VJ7xZhQu3/exportTemplate?api-version=2017-08-01", "", "Accept"=>"application/json", "Accept-Encoding"=>"gzip, deflate", "Authorization"=>"Bearer [FILTERED] ", "Content-Length"=>"0", "Content-Type"=>"application/json", "User-Agent"=>"rest-client/2.0.2 (linux-gnu x86_64) ruby/2.4.4p296"

The next log message for thread #35053 is another GET a minute later.
[----] W, [2018-07-16T14:20:35.824317 #35053:c9cf84]  WARN -- : RestClient.get "https://management.azure.com/subscriptions?api-version=2016-06-01", "Accept"=>"application/json", "Accept-Encoding"=>"gzip, deflate", "Authorization"=>"Bearer [FILTERED] ", "Content-Type"=>"application/json", "User-Agent"=>"rest-client/2.0.2 (linux-gnu x86_64) ruby/2.4.4p296"

It seems like the exportTemplate call is taking a long time to respond and this is causing the entire refresh process to halt.



Expected behavior:
The refresh should continue even if fetching portions of the inventory encounter failures.



Version-Release number of selected component (if applicable):
First observed on 5.10.0.4

Comment 2 Daniel Berger 2018-07-17 13:50:56 UTC

*** This bug has been marked as a duplicate of bug 1600968 ***


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