Details
-
Bug
-
Status: Closed
-
Normal
-
Resolution: Fixed
-
None
-
Platform Core
-
Platform Core KANBAN
-
Bug Fix
-
The {{lookup}} command line tool did not set facts given on the command line such that they ended up in {{$facts}} variable.
-
Automate
-
We should make a test for this in puppet and facter
Description
I was trying to simulate a change to my $facts['networking'] fact, so I ran facter --json > ~/Desktop/facts.json, edited the appropriate spot, and tried to pass that to puppet lookup --facts. No dice: my change was ignored.
That's because I was using facts.networking in my hierarchy, and apparently --facts doesn't actually set the $facts variable — it just sets top-scope variables with names from the JSON.
- Problem one: That's unexpected, and it interferes with using facter --json as a basis for simulating other nodes.
So, I tried wrapping the facts json in another object with only a "facts": key. Which resulted in the following error: "Error: Could not run: Attempt to assign to a reserved variable name: 'facts'"
- Problem two: If your hierarchy uses the $facts variable like we recommend (instead of ::factname vars), it's impossible to simulate any changes with the puppet lookup CLI. I expect this blocks setting other values for $trusted or $server_facts, as well.
The first problem goes into the bucket of things we need to discuss around puppet lookup's UX. The second problem seems like a straight-up defect.
Attachments
Issue Links
- relates to
-
PUP-10435 facts provided in a file cannot be used for classification
-
- Resolved
-