ok hrm originally i handled this with a top level variable that 'everything else used'. puppet lint yelled at me for that and i let puppet lint tell me how to live my life (haha) seriously though -- it sounds like i'd be better off reversing course and sticking with my original plan of setting it at the top level and not having a million lookups of the same thing and just tell lint to ignore it -- thanks!

(lint is of course assuming i'm doing a top level fact, not a top scope variable)

I mean you need to understand what puppet server is doing at the end of the day, it's using a git repo, with a data location to lookup a value on disk, that disk file might be cached in the OS's memory, and it might matter if the file(s) are very large (in terms of scanning to find the right lookup value) but again, this is just OS functions not the server itself doing something special

of course puppet server knows that there are several locations to find potential values, in the hiera.yaml, and it will exhaust that list attempting to find the right key/value lookup asked for

but again, this is just puppet server doing what it was told, so you're miliage will depend entirely on how this was built and runs, each operation has a cost associated with it and that cost is based on the lookups needed, the size of the files on disk, the speed of the disk access, etc etc etc

that all makes perfect sense -- was just something i wanted to clarify before i went changing a bunch of stuff just because lint questioned my lineage 😉 thanks!

@Daniel Henninger Hiera does a lot of caching of data. If the looked up data comes from a json/yaml it will most likely be delivered from the cache on subsequent lookups. For hiera backends based on ”lookup key” variant of the API caching is up to the implementation of that backend - there is caching support in the API but how/if it is used is up to the implementation of the backend function.

Yeah. Hiera does have support for caching, but for 3rd-party backends it is up to the author to use it. You definitely want to think about caching if when writing a Hiera backend as it will get quite a scale of traffic. Doubly so if your backend is making network calls to external services.

Hi. I'm trying to migrate my puppet clients from one puppet server to another. And there's a problem with $:: hostname fact. On client and on Foreman it shows un capital letters but looks like on new Puppetserver it's in small letters and some code doesn't work. On old server code works. Can you please help me figure what setting changes this behavior? Thank you.

message has been deleted

has anyone every seen a fact looping almost in an endless loop? If I run puppet with

--debug

I see the fact

ip6tables_version.rb

being called gazillions of times, and it causes the agent to run for 220 seconds, only looping on this fact execution.

but there is not wrong with this facts, and it's almost the same as

iptables_version.rb

(it changes only the name of the command)

apparently is being called by a provider

YES!

This message was deleted.

Fact-loop?

so, when you reference an external fact from another fact, it fork-bombs your machine if you don’t use the appropriate command line argument

I’m looking for the ticket I reported a few years ago

Ah. Yeah; I wound up converting all our external facts to custom facts awhile back to resolve a similar problem.

Ah. Yeah; I wound up converting all our external facts to custom facts awhile back to resolve a similar problem.

all you have to do is add

--no-external-facts

to the external fact call

as in

facter -p --no-external-facts myfactname

?

yeah. So, I told our folks to use facter whenever possible, even in their own facts. Think IP addresses… We had a network device that was ALWAYS on networkaddress.3, so I was extrapolating from the network address what that device’s IP was, and using the network fact (facter networking.network) and then stripping the “.0” from the end, and adding the “.3" So, I was sourcing a fact from within a fact… when the fact got resolved, for some reason it fork-bombed with tons of facter processes

The resolution of the fact within the fact was the issue. I opened a ticket I don’t seem to be able to find right now, and that was the recommendation within the fact to just call facter like so:

facter <lookup> --no-external-facts

I don’t doubt it might be the same with Ruby facts. The second the facts.d method came along, I switched wholesale to that rather than keeping with Ruby facts since pluginsync moves them, and we can write them in BASH

Here it is…. This was even older in my career than I thought. This was 2011:

Facter.add("bluecat1") do
     setcode do
        %x{facter -p ipaddress |/usr/bin/awk -F "." '{print $1"."$2"."($3+1)"."4  }'}.chomp
     end
  end

So, I was doing a facter call from inside facter, and that fork-bombed. Instead, I did this:

Facter.add("bluecat1") do
     setcode do
        %x{facter -p ipaddress --no-external-facts |/usr/bin/awk -F "." '{print $1"."$2"."($3+1)"."4  }'}.chomp
     end
  end

worked perfectly

beaker 🧑‍🏫 Bolt is about to start up in #CFD8Z9A4T

hmm, why not use

Facter::value(:ipaddress)

instead ?

it's a bug in the firewall module: https://github.com/puppetlabs/puppetlabs-firewall/issues/1071

it's a bug in the firewall module: https://github.com/puppetlabs/puppetlabs-firewall/issues/1071