Ah yeah I forgot that puppet splits out the special “classes” hash from the ENC and applies it at the node scope. So this is an ordering thing.
The scope hierarchy goes like this ENC > site.pp > node. Hiera is applied at the node scope but has access to the top scope and data from the ENC classes hash overrides data from Hiera.
Try this for example in site.pp you should get the current host group for the node just to illustrate the main ENC data is there at site.pp time.
notify {"Hello $hostgroup from ...":}
also note, as a test, if you include another class in the site.pp you’ll be able to get the param value from the class. It’ll have to be a class that’s not included for the node via foreman though otherwise you’ll get a duplicate declaration error.
include role::yyy
notify {"Hello $role::yyy:self from ...":}
So the reason you can’t get the variable is because the class hasn’t been included yet at the time site.pp is parsed.
The smart params you set will be available when hiera is parsed though so you might be able to do away with the logic in site.pp and let heira select the right yaml file to include from variables set in the classes.
The only issue will be replacing what you’re doing in site.pp which is collapsing many different name-spaced variables to a single top level variable you can reference as part of the hierarchy.
We include a set of global classes from foreman so that every node has a common place we can reference. See here for a write up Info to move foreman to hiera - want to build a guide - #4 by Matt_Cahill
It’s slightly changed since that was written because smart variable went away so we now use a smart class parameter in our hiera hierarchy like this (which is why i’m confident about the fact your vars will be there in hiera)
- name: "Foreman Hostgroup specific data"
mapped_paths: ["foreman_enc::params::global::parent_hostgroup_paths", hostgroup_path, "21_hostgroups/%{hostgroup_path}.yaml"]
So every hostgroup gets it’s own hiera data and we also provision nodes with trusted facts via CSR attributes so you can bootstrap a node with a role
- name: "Role specific data"
path: "20_roles/%{trusted.extensions.pp_department}/%{trusted.extensions.pp_team}/%{trusted.extensions.pp_environment}/%{trusted.extensions.pp_role}.yaml"
If i think of anything i’ll let you know but probably you’ll want to experiment with mapped_paths and the classes hash in hiera. You may not even need the parameter any more and you’ll be able to hit a yaml file just by the class name being included from foreman.