during testing of IPv6 provisioning via discovery I ran into issue with Facter 2.x we use on the image. It looks like facter does not show all IPv6 addresses for some reason. A host with IPv6 only network does have
ipaddress6 fact set properly, however
ipaddress6_eth0 is missing and since discovery still uses legacy facts to detect NICs it won’t work with IPv6.
I am wondering, what blocks us from shipping Facter 4.x in our repositories?
I was trying to find facter in PL repos but it looks like I am either blind or facter is getting shipped in a different package:
For the record, the packaging change is just a version bump to 4.0.35 plus a new rubygem dependency (hocon, a configuration parser library). Not bad.
I think not a lot. It’s required by Foreman:
However, that’s pretty open. That’s because we only use it for very trivial things:
In the past I already minimized the use:
We can probably drop it and replace it with
Socket.gethostname plus logic to make it a FQDN
However, to answer your question: in the short term you can probably safely update since the API’s we rely on still work. We can’t rely on the PL packages since they ship their own Ruby stack so the gems can’t be loaded.
Sure, good idea. However according to my preliminary testing, Facter 4.x API appears to be compatible with 2.x, so it should work out of box after the upgrade.
Anyway, I will go ahead with the packaging changes and test first if it does not break discovery. Thanks.
It’s weird that we do not have a version pin on Facter in bundler actually, so we already use 4.x during development
We should probably pin this, not a big deal I guess.
$ ag facter bundler.d/
1:group :facter do
2: gem 'facter'
Ok, @ekohl noticed that Facter 4.x requires Ruby 2.3 which is not the case for non-scl Ruby in RHEL7 (2.0). Therefore Facter cannot be upgraded until all scripts/menu/code written in Ruby is built and tested on SCL Ruby.
It’s doable, but its getting worse and worse.