Allow digging into fields of facts when they are a hash on old puppets#656
Allow digging into fields of facts when they are a hash on old puppets#656albertvaka merged 3 commits intomasterfrom
Conversation
albertvaka
force-pushed
the
albertvaka/facts-dig
branch
5 times, most recently
from
d5a251f to
35b5de1
Compare
If a `facts_to_tags` tag looks like a hash path (eg: 'networking.domain'), dig that path into the hash and use the inner value for the tag. For backwards compatibility, if the name looks like a hash path but there's a fact that's an exact string match (eg: there's a fact named 'networking.domain') then that will be used for the tag.
albertvaka
force-pushed
the
albertvaka/facts-dig
branch
from
35b5de1 to
39d8c27
Compare
albertvaka
changed the title
albertvaka
changed the title
albertvaka
changed the title
| agent_major_version: 6, | ||
| puppet_run_reports: true, | ||
| facts_to_tags: ['osfamily', 'facts_array'], | ||
| facts_to_tags: ['osfamily', 'facts_array', 'facts_hash.actor.first_name', 'looks.like.a.path'], |
There was a problem hiding this comment.
What should the output be with something like facts_hash.path.like.key and:
'facts_hash' => {
'path.like.key' => 'something',
},
? I am not sure what is it that we want in that case.
Docs say this should be referenced as 'facts_hash."path.like.key"'; we could add a test with that.
There was a problem hiding this comment.
In general, I would say that keys like path.like.key shouldn't be used... This PR handles this case only to not break backwards compatibility (in case someone is using weird keys like that), but I don't think we need to support every edge case down that rabbit hole. Otherwise..
'facts_hash' => {
'path.like.key' => {
"actual.hash" => "I'm evil"
}
},
Docs say this should be referenced as
'facts_hash."path.like.key"'; we could add a test with that.
Which docs? That syntax doesn't work with the current code.
There was a problem hiding this comment.
Docs say this should be referenced as
'facts_hash."path.like.key"'; we could add a test with that.Which docs? That syntax doesn't work with the current code.
The Puppet 6.18 get function docs, just above the one you link in the PR's description (getvar calls get at some point).
My point with this was that if what we want is to truly replicate getvar behavior we should deal with this; it's fine for me if we don't, it doesn't look like a very likely case.
DataDog#656) If a facts_to_tags tag looks like a hash path (eg: 'networking.domain'), dig that path into the hash and use the inner value for the tag. For backwards compatibility, if the name looks like a hash path but there's a fact that's an exact string match (eg: there's a fact named 'networking.domain') then that will be used for the tag. Note that on Puppet 6.0 and later `getvar` already behaves like this, so this only makes it work on old Puppets.
2 participants
What does this PR do?
If a
facts_to_tagstag looks like a hash path (eg: 'networking.domain'),dig that path into the hash and use the inner value for the tag.
For backwards compatibility, if the name looks like a hash path
but there's a fact that's an exact string match (eg: there's a fact named
'networking.domain') then that will be used for the tag.
Note that on Puppet 6.0 and later
getvaralready behaves like this,so this only makes it work on old Puppets.
Motivation
Feature request.