This message was deleted.
# puppet
s
This message was deleted.
b
ie: is the 'epp' section heria-ifyable?
I'm very close with:
foo:
'clear_cache':
command: "epp('puppet_nfii/sssd_join.epp'), { admin_password: %{lookup('admin_password')}, admin_name: %{lookup('admin_name')} }"
timeout: 60
tries: 2
notify:
- Exec[clear_cache]
- Service[sssd]
But I think I've just reproduced a string, not a resource.
l
if it 's in a module called sssd, and admin_name, admin_password, and computers_ou are parameters to sssd, then you can skip the lookup and just reference the variables
because hiera Automatic Parameter Lookup will take care of it
but I don't entirely make resources into hiera ever
b
I'm using sgnl05-sssd module; there aren't any admin/password parameters so I have to use lookup to populate my EPP file.
d
l
I'd suggest a profile
this is exactly what profiles are for 🙂
b
I've got hiera separated into RedHat and OraclLinux hierarchies so in my RedHat.yaml file, I wanted to create the exec resource rather than "if os = redhat then <build this>, else <build that>"
Perhaps I'm using roles and profiles wrong but I've got almost everything in hiera.
l
yea, you can still do that, but it will be much less complex if you can have a real exec resource and APL
profile::sssd could have all the variables you need in addition to the sssd standard ones
and then you can just have the exec using profile_sssd::admin_password etc
and set them in the os/ hiera dirs
b
I'll see if I can make that happen. Thanks for the help.
l
hope it works out
y
I have a strong opinion that putting resource definitions into Hiera is anti-pattern.. though I know there is a lot of ppl who uses it and they are happy with it.