Details
-
Bug
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
FACT 4.0.52
-
None
-
Night's Watch
-
3
-
NW - 2021-03-31
-
Needs Assessment
-
Bug Fix
-
Fix an issue where the cloud fact can take over 20 seconds to resolve on Windows due to Ruby not respecting the HTTP connection timeout. Now the fact is only resolved on HyperV machines, and a workaround was implemented to avoid long timeouts.
-
Needs Assessment
Description
The azure metadata fact takes 20+ seconds before timing out on Windows.
$ cmd /c facter --version
|
4.0.52
|
|
|
$ time cmd /c facter > /dev/null
|
real 0m22.431s
|
user 0m0.000s
|
sys 0m0.000s
|
When running with debug you can see:
[2021-03-17 01:49:16.036357 ] DEBUG Facter::Resolvers::Az - Querying Az metadata
|
[2021-03-17 01:49:37.076303 ] DEBUG Facter::Util::Resolvers::Http - Trying to connect to http://169.254.169.254/metadata/instance?api-version=2020-09-01 but got: execution expired
|
The EC2 fact uses the same IP address, so I'm not sure if the EC2 fact is blocked by default, or is excluded based on other criteria, or because the EC2 fact uses a very small connect timeout: https://github.com/puppetlabs/facter/blob/f169f54ddae91787b2f36a25d6e7cbc2330c5bbc/lib/facter/util/resolvers/http.rb#L10
Redhat8 doesn't have this issue:
[2021-03-17 00:53:25.649111 ] DEBUG Facter::Resolvers::Az - Querying Az metadata
|
[2021-03-17 00:53:25.670289 ] DEBUG Facter::Util::Resolvers::Http - Trying to connect to http://169.254.169.254/metadata/instance?api-version=2020-09-01 but got: Failed to open TCP connection to 169.254.169.254:80 (Network is unreachable - connect(2) for "169.254.169.254" port 80)
|