| Hello, In attempting to block a specific fact, I ran into some inconsistent behavior. I could block some facts, but not others. I opened a thread on the puppet-community slack: https://puppetcommunity.slack.com/archives/C0W298S9G/p1677263313600889 Here are a couple examples of facts that fail to be blocked:
$ echo -e 'facts: { blocklist: [ "blocked" ] }\nfact-groups: { blocked: [ "networking.interfaces.lo" ] }' > facter.conf && facter -j -c facter.conf | jq '.networking.interfaces.lo.ip' |
"127.0.0.1" |
|
$ echo -e 'facts: { blocklist: [ "blocked" ] }\nfact-groups: { blocked: [ "ec2_metadata.managed-ssh-keys.signer-cert" ] }' > facter.conf && facter -j -c facter.conf | jq '.ec2_metadata."managed-ssh-keys"."signer-cert"' | wc -c |
7067
|
The first example should be more generally testable; the second example requires an AWS EC2 host and shows the fact I was intending to block. Josh Cooper investigated this and was able to diagnose a bit further.
Implementation-wise there are a few different use-cases:
- blocking an entire structured fact, e.g. uptime
- blocking a sub-element of a structured fact, e.g. memory.system.available
- blocking a dynamically generated sub-element, e.g. partitions.<device>
- blocking legacy facts
I think all of those work except for the third one, for example, this is using current head of facter:
$ echo -e 'facts: { blocklist: [ "blocked" ] }\nfact-groups: { blocked: [ "networking.interfaces.lo" ] }' > facter.conf && bundle exec facter -j -c facter.conf | jq '.networking.interfaces.lo.ip' |
"127.0.0.1"
|
Thanks,
Corey
|
