Api call discovered_hosts/:id/refresh_facts removes lldp facts from foreman

Problem:
After machine gets discovered and after PUT to /discovered_hosts/:id/refresh_facts lldp facts disappear from discovered host facts. Running manually discover-menu over ssh from inside of fdi booted machine restores lldp information.

Expected outcome:
lldp information should not be excluded when refreshing facts

Foreman and Proxy versions:
1.24.2
Foreman and Proxy plugin versions:
latest released
Distribution and version:
CentOS 7
Other relevant data:

Hello, FDI image version? I think I’ve seen this and fixed this bug. Can you try nightly:

http://downloads.theforeman.org/discovery/nightly/

3.5.7. I will try nightly.

On nigtly (booted through UEFI, intel i210 nics - only one connected to switch with copper cable):

Refreshing facts through foreman UI gives me:
ERF50-7522 [Foreman::WrappedException]: Failed to refresh facts for mac with error wrong number of arguments (given 0, expected 1) ([ArgumentError]: wrong number of arguments (given 0, expected 1))

Then I tried to log into discovery system through ssh and run lldptool -tni eno1 and lldptool -ti eno1 and they don’t return anything at all. lldptool -i eno1 -S shows all zeros in output. All those commands work as expected with 3.5.7.

Can you give the stacktrace? Might need to enable debug in foreman.

Sorry for the late reply.
With FDI 3.5.7 LLDP facts are there on initial discover - refreshing facts somehow loses LLDP facts, but refresh does not cause any error.
With FDI 3.6.2 LLDP facts are not there on initial discover and refreshing facts causes error described above with logs below

Ideally refreshing facts should always work and not make LLDP facts disappear no matter FDI version.
Foreman 2.1.0

Ok, getting there :slight_smile:

The proxy returned “400 Bad Request” and we need to see what happened there. Paste proxy.log, ideally with debug turned on.

2020-08-03T16:46:50  [D] accept: 10.32.34.22:39960
2020-08-03T16:46:50  [D] Rack::Handler::WEBrick is invoked.
2020-08-03T16:46:50 63d8afd1 [I] Started GET /discovery/10.32.85.15/inventory/facter 
2020-08-03T16:46:50 63d8afd1 [D] verifying remote client 10.32.34.22 against trusted_hosts ["proxy-1.home.local", "proxy-2.home.local", "node-1.home.local"]
2020-08-03T16:46:50 63d8afd1 [E] Proxy error HTTP 400 (400 Bad Request): uninitialized constant Proxy::DiscoveryImage::InventoryApi::Facter)
2020-08-03T16:46:50 63d8afd1 [W] Error details for Proxy error HTTP 400 (400 Bad Request): uninitialized constant Proxy::DiscoveryImage::InventoryApi::Facter): <Exception>: Proxy error HTTP 400 (400 Bad Request): uninitialized constant Proxy::DiscoveryImage::InventoryApi::Facter)
2020-08-03T16:46:50 63d8afd1 [W] Proxy error HTTP 400 (400 Bad Request): uninitialized constant Proxy::DiscoveryImage::InventoryApi::Facter): <Exception>: Proxy error HTTP 400 (400 Bad Request): uninitialized constant Proxy::DiscoveryImage::InventoryApi::Facter)
2020-08-03T16:46:50 63d8afd1 [I] Finished GET /discovery/10.32.85.15/inventory/facter with 400 (99.33 ms)
2020-08-03T16:46:50  [D] close: 10.32.34.22:39960

Allright, it looks like there is a problem with facter on FDI. Need to take a look.

Looks like the FDI image is missing Facter in TFM SCL, therefore this API call fails:

# tfm-ruby -e "require 'facter'"
Traceback (most recent call last):
	2: from -e:1:in `<main>'
	1: from /opt/rh/rh-ruby25/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require'
/opt/rh/rh-ruby25/root/usr/share/rubygems/rubygems/core_ext/kernel_require.rb:59:in `require': cannot load such file -- facter (LoadError)

FDI image 3.6.4 will fix it: http://downloads.theforeman.org/discovery/nightly/

1 Like

Refreshing facts works with 3.6.4. Still LLDP facts don’t work reliably or at all.
With FDI 3.5.7 LLDP facts are there on initial discover - refreshing facts somehow loses LLDP facts.
With FDI 3.6.4 LLDP facts don’t work at all.

Please ssh to the host, investigate why it does not work. LLDP are custom facts that facter should pick up:

The FDI still uses Facter 2.x, upgrade is planned.

I will try to debug this problem and report my findings. Can you please link the issue where Facter upgrade is tracked?

https://projects.theforeman.org/issues/24153

1 Like