Details
-
Bug
-
Status: Resolved
-
Normal
-
Resolution: Fixed
-
None
-
None
-
-
Night's Watch
-
5
-
NW - 2021-10-20, NW - 2021-11-03, NW - 2021-11-17, NW - 2021-12-06
-
Customer Feedback
-
Reviewed
-
Bug Fix
-
Fix an issue where trusted facts couldn't be used as rules for classification. This was fixed by gathering the trusted facts from the puppetdb query result, and overriding the trusted facts context.
-
Needs Assessment
Description
I have 2 environments, production and acceptance.
I have an environment group for Acceptance:
node_group { 'Acceptance Environment':
|
ensure => 'present',
|
environment => 'acceptance',
|
id => '539f71ae-50d3-42f6-8201-289dba160ba5',
|
override_environment => 'true',
|
parent => 'Production environment',
|
rule => ['and',
|
['~',
|
['trusted', 'extensions', 'pp_role'],
|
'agent']],
|
}
|
'Production Environment' node group has not been modified.
When I run puppet agent in a node with pp_role = agent, I confirm that it is using the right environment:
[root@10-32-175-131 ~]# puppet agent -t
|
Notice: Local environment: 'production' doesn't match server specified node environment 'acceptance', switching agent to 'acceptance'.
|
Yet when I try to do a lookup for that node, the data retrieved is from Production:
puppet lookup --node 10-32-175-131.rfc1918.puppetlabs.net message --explain
|
Searching for "message"
|
Global Data Provider (hiera configuration version 5)
|
Using configuration "/etc/puppetlabs/puppet/hiera.yaml"
|
Hierarchy entry "Classifier Configuration Data"
|
No such key: "message"
|
Environment Data Provider (hiera configuration version 5)
|
Using configuration "/etc/puppetlabs/code/environments/production/hiera.yaml"
|
Hierarchy entry "Per-node data"
|
If I pin the node to the "Acceptance Environment" group, I get the right output for lookup:
node_group { 'Acceptance Environment':
|
ensure => 'present',
|
environment => 'acceptance',
|
id => '539f71ae-50d3-42f6-8201-289dba160ba5',
|
override_environment => 'true',
|
parent => 'Production environment',
|
rule => ['or',
|
['and',
|
['~',
|
['trusted', 'extensions', 'pp_role'],
|
'agent']],
|
['=', 'name', '10-32-175-131.rfc1918.puppetlabs.net']],
|
}
|
root@10-32-175-155.rfc1918.puppetlabs.net /root> puppet lookup --node 10-32-175-131.rfc1918.puppetlabs.net message --explain
|
Searching for "message"
|
Global Data Provider (hiera configuration version 5)
|
Using configuration "/etc/puppetlabs/puppet/hiera.yaml"
|
Hierarchy entry "Classifier Configuration Data"
|
No such key: "message"
|
Environment Data Provider (hiera configuration version 5)
|
Using configuration "/etc/puppetlabs/code/environments/acceptance/hiera.yaml"
|
Found the issue in LTS, reproduced in 2017.3.0.
EDIT: A rule created with an out-of-the-box fact like domain honors the environment. A rule created with a trusted fact defaults to production. A mix of trusted + normal fact, like trusted.extensions.pp_role + domain defaults to production.
Attachments
Issue Links
- blocks
-
PUP-8539 Hiera trusted fact lookup
-
- Closed
-
-
PUP-7479 ENC-enforced environment makes `puppet lookup` environment simulation difficult
-
- Resolved
-
- is caused by
-
PUP-8502 Puppet lookup always includes classes from the ENC
-
- Closed
-
- is duplicated by
-
PUP-9207 puppet lookup --compile returns incorrect results when trusted facts define environment
-
- Closed
-
- relates to
-
PUP-8220 Verify trusted facts are overridden consistently
-
- Resolved
-
-
PUP-6400 lookup cli has no way to set arbitrary scope values
-
- Accepted
-