Best practice for locating data in hiera vs. manifest
We're completely refactoring our manifests for the 3rd time after studying Gary Larizza's excellent blog post series. We've adopted the role/profiles pattern and every other best practice we could pickup. However we've ended up storing data inconsistently between hiera and the profile manifests. Puppet provides a huge amount of rope to hang oneself in this area. For example, we did the following:
- We have a profile::base class that collects all crontab entries across all servers i.e. create_resources(cron, $crontabs)
- Similarly we have a profiles::apache class that creates vhosts i.e. create_resources(apache::vhost, $apache_vhosts)
- Similarly we have a profile::mysql class that passes a hash of users+grants+databases from hiera to the mysql::server class.
This results in thin profile manifests and fat hiera frames. It feels as if our data is split inconsistently across the profile manifest and hiera. In 2013 Gary wrote in http://garylarizza.com/blog/2013/12/0... that the only data that should go into hiera is:
- Business-specific data (i.e. internal NTP server, VIP address, per-environment java application versions, etc…)
- Sensitive data
- Data that you don’t want to share with anyone else
This implies that we're severally abusing create_resources and that we should actually have 95% of the data in the profile manifests. When setting up a webserver instead of the profile manifests explicitly declaring the vhosts required using apache::vhost, we just include profile::apache. So by looking at the manifest you actually have no idea of how the profile is setup and have to consult hiera (which means checking through the whole hierarchy).
Can anyone using/familiar with the profiles/roles pattern comment on how they are using hiera i.e. are you explicitly defining resources in the manifest or are you using create resources wherever possible?