Plugins » Discovery

current:

discovery_release     20170104.1
discovery_version     3.3.1
facterversion         2.4.1

discovery_release     20170331.1
discovery_version     3.4.0 
facterversion         2.4.1 

Ok thanks, 3.4.0 is the latest, I haven't pushed 3.4.1 yet, but there were no changes in this regard.

I am unable to reproduce, can you attach full journald log of the whole boot with 3.4.0 version?

When you refresh facts, do you also see facts named "nmprimary_*" to disappear?

Hmmm nothing really useful in logs, I need to reproduce, but I don't have any LLDPAD enabled switch. Need to figure out how do I test this in libvirt environment. I don't see any LLDPAD facts reported in libvirt VM.

may you are able to create an open virtual switch and bridge it to your virtual env. something bit more in detail described here: http://blog.scottlowe.org/2016/12/09/using-ovn-with-kvm-libvirt/

Uh that's lot of work, let me try to remotely debug with you first :-)

Can you sign into the FDI and after it's booted and you verify that Refresh Facts does not work correctly, can you do:

FACTERLIB=/usr/share/fdi/facts/ facter

Do you see missing facts? I'd assume no (proxy does the same thing essentially). Then run this:

facter interfaces
lldptool get-tlv -n -i NETWORK_INTERFACE_FROM_ABOVE -V 1
lldptool get-tlv -n -i NETWORK_INTERFACE_FROM_ABOVE -V 5
lldptool get-tlv -n -i NETWORK_INTERFACE_FROM_ABOVE -V 8

Here is the custom fact which gets the facts, feel free to edit it in case you find why it does not work:

https://github.com/theforeman/foreman-discovery-image/blob/master/root/usr/share/fdi/facts/openlldp.rb

after confirming the host is having missing lldp facts after a facts refresh i logged in to the FDI and run the following command:

FACTERLIB=/usr/share/fdi/facts/ facter

lldp_neighbor_chassisid_eno49 => ec:XX:91:XX:XX:XX
lldp_neighbor_chassisid_eno50 => XX:fe:XX:d2:XX:XX
lldp_neighbor_mngaddr_ipv4_eno49 => XX.XX.XX.130
lldp_neighbor_mngaddr_ipv4_eno50 => XX.XX.XX.131
lldp_neighbor_portid_eno49 => Gi0/15
lldp_neighbor_portid_eno50 => Gi0/15
lldp_neighbor_pvid_eno49 => 700
lldp_neighbor_pvid_eno50 => 700
lldp_neighbor_sysname_eno49 => some-systems-fqdn.internal
lldp_neighbor_sysname_eno50 => some-other-systems-fqdn.internal

facter interfaces

eno49,eno50,lo

[root@fdi ~]# lldptool get-tlv -n -i eno49 -V 1
Chassis ID TLV
    MAC: ec:XX:91:XX:XX:XX
[root@fdi ~]# lldptool get-tlv -n -i eno49 -V 5
System Name TLV
    some-systems-fqdn.internal
[root@fdi ~]# lldptool get-tlv -n -i eno49 -V 8
Management Address TLV
    IPv4: XX.XX.XX.130
    System port number: 0

So basically you say that after facts refresh, you do not see LLDP facts but facter shows them?

Now let's find out what smart-proxy shows via its API (it just calls Facter API), run this:

curl http://192.168.122.xx:8448/facts | json_reformat

If you don't have json_reformat just reformat the garbage with an online tool and find what you want to see. Two options:

1) It's missing - a bug in FDI when proxy does not see those facts (or they might fail in proxy context - I am not sure if we capture STDERR there)

2) It's there - then foreman_discovery must filter these out somehow, but I can't think of anything that would do it.

LZ

Yes, thats what i am basically saying.
i am having troubles connecting via curl or wget to the smart proxy. i am always getting below output:

[root@fdi ~]# curl -k https://10.X.X.X:8443/facts
Requested url was not found

I, [2017-07-28T10:21:25.280982 ]  INFO -- : 10.X.X.X - - [28/Jul/2017 10:21:25] "GET /facts HTTP/1.1" 404 27 0.0004

So it seems it is not finding /facts for whatever reason. am i doing something wrong?

Hmm that could be the bug. In the journald log I can clearly see the facts component starts up:

Jul 10 11:07:59 fdi foreman-proxy[1630]: 'facts' settings: 'enabled': true

Can you check that?

curl -k https://10.X.X.X:8443/features

Should list "facts" module loaded, then you really should be able to hit it via /facts.

looks like that feature is not visible/enabled on the foreman-proxy:

[root@fdi ~]# curl -k https://XXXXXXXXXX:8443/features
["dhcp","discovery","salt","templates","tftp"] 

looks like that feature is not visible/enabled on the foreman-proxy:

Wait, I want you to run this against discovered node, there is also a foreman-proxy there but running different set of modules. It is used to expose some basic API for reboot/kexec and also facts.

oh, i misunderstood that. running it agains the discovered node shows obviously that this feature is available:

# curl -k https://XXX.XXX.XXX:XXX:8443/features 
["bmc","discovery_image","facts","logs"]

"nmprimary_connection_lldp": "-1 (default)", 

Dominic Schlegel wrote:

oh, i misunderstood that. running it agains the discovered node shows obviously that this feature is available:
[...]
getting /facts from the discovered node now just gives me 1 fact that has "lldp" in its name:
[...]
but unfortunately no fact like lldp_neighbor_*

Okay we are getting there. To sum up (please try):

• FACTERLIB=/usr/share/fdi/facts/ facter | grep lldp
• curl -k https://10.X.X.X:8443/facts | grep lldp

So while the first one shows lldp facts the other does not, please confirm.

Then can you check foreman-proxy.service file for env variable for Puppet:

1. grep EnvironmentFile /usr/lib/systemd/system/foreman-proxy.service
   EnvironmentFile=/etc/default/discovery

And then

1. cat /etc/default/discovery
   FACTERLIB=/usr/share/fdi/facts:/opt/extension/facts

Puppet version is? I assume you use the official build with Puppet from EPEL?

• curl/wget proxy on FDI

correct. the first one does show some lldp facts:

[root@fdi ~]# FACTERLIB=/usr/share/fdi/facts/ facter | grep lldp
lldp_neighbor_chassisid_eno49 => ec:30:XX:XX:XX:XX
lldp_neighbor_chassisid_eno50 => 04:fe:XX:XX:XX:XX
lldp_neighbor_mngaddr_ipv4_eno49 => 10.XX.XX.XXX
lldp_neighbor_mngaddr_ipv4_eno50 => 10.XX.XX.XXX
lldp_neighbor_portid_eno49 => Gi0/22
lldp_neighbor_portid_eno50 => Gi0/22
lldp_neighbor_pvid_eno49 => 700
lldp_neighbor_pvid_eno50 => 700
lldp_neighbor_sysname_eno49 => my-switches-name
lldp_neighbor_sysname_eno50 => my-switches-name2
nmprimary_connection_lldp => -1 (default)

curl --cert /tmp/cert.pem --key /tmp/key.pem -k https://xx.xx.xxx.x:8443/facts  | grep lldp
"nmprimary_connection_lldp":"-1 (default)",

[root@fdi ~]# grep EnvironmentFile /usr/lib/systemd/system/foreman-proxy.service
EnvironmentFile=-/etc/default/discovery
EnvironmentFile=-/etc/sysconfig/foreman-proxy

[root@fdi ~]# cat /etc/default/discovery
PATH=/usr/local/sbin:/usr/local/bin:/usr/sbin:/usr/bin:/opt/extension/bin
FACTERLIB=/usr/share/fdi/facts:/opt/extension/facts
LD_LIBRARY_PATH=/opt/extension/lib
RUBYLIB=/opt/extension/lib/ruby

in the meanwhile i am using FDI 3.5.7 and i am missing the lldp_* facts even from first initial facts upload.

i figured out the underlying problem of this:

some cisco switches will send lldp packets tagged with vlan 1 when the port mode is set to trunk and the native vlan is set to something else. this leads to the case that the switch sends those lldp packets but the server's nic will trash the packet as it is tagged with vlan 1 and this is out of interest of the server. there are 2 possible solutions for this:

1. set the port mode to acccess with the corresponding correct vlan id. in this case the switch will not tag lldp packets with vlan id 1 and the server receives it properly.
2. set all interfaces in the foreman discovery image to promiscuous mode.