Jira (FACT-3189) facter cannot block some facts

0 views
Skip to first unread message

Corey Hickey (Jira)

unread,
Mar 1, 2023, 6:00:02 PM3/1/23
to puppe...@googlegroups.com
Corey Hickey created an issue
 
Facter / Bug FACT-3189
facter cannot block some facts
Issue Type: Bug Bug
Affects Versions: FACT 4.2.14
Assignee: Unassigned
Components: Facter 4
Created: 2023/03/01 2:59 PM
Environment:

I'm using facter 4.2.7 on AlmaLinux 8.7.

This is also reproducible with facter from recent git (2a75849d7b47baebb05b840a0d5d7a4bf66f0e29 and presumably later as well).

Priority: Normal Normal
Reporter: Corey Hickey

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

Add Comment Add Comment
 
This message was sent by Atlassian Jira (v8.20.11#820011-sha1:0629dd8)
Atlassian logo

Corey Hickey (Jira)

unread,
Mar 1, 2023, 6:01:03 PM3/1/23
to puppe...@googlegroups.com
Corey Hickey updated an issue
Change By: Corey Hickey
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:
{code}
$ 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
{code}

The first example should be more generally broadly testable; the second example requires an AWS EC2 host and shows the fact I was intending to block.

[~josh] investigated this and was able to diagnose a bit further.
{quote}

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:
{code}
$ 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"
{code}
{quote}

Thanks,
Corey

{quote}

Michael Hashizume (Jira)

unread,
Mar 7, 2023, 4:35:02 PM3/7/23
to puppe...@googlegroups.com
Michael Hashizume updated an issue
Change By: Michael Hashizume
Epic Link: PUP-11659

Michael Hashizume (Jira)

unread,
Mar 7, 2023, 4:36:02 PM3/7/23
to puppe...@googlegroups.com
Michael Hashizume updated an issue
Change By: Michael Hashizume
Labels: needs-validation
Reply all
Reply to author
Forward
0 new messages