hiera 5 compatibility
Opened this issue · 8 comments
Affected Puppet, Ruby, OS and module versions/distributions
- Puppet: 4.9.2
- Ruby: 2.1.9
- Distribution: Ubuntu trusty
- Module version: 2.4.0
How to reproduce (e.g Puppet code you use)
hiera::owner: root
hiera::group: root
hiera::backends:
- yaml
- file
hiera::backend_options:
yaml:
datadir: "/etc/puppetlabs/code/environments/%{literal('%')}{::environment}/hieradata"
file:
datadir: "/etc/puppetlabs/code/environments/%{literal('%')}{::environment}/hierafiles"
hiera::merge_behavior: deeper
hiera::hierarchy:
- "fqdn/%{literal('%')}{::fqdn}"
- "roles/%{literal('%')}{role}"
- "vm_profiles/%{literal('%')}{vm_profile}"
- "vm_parents/%{literal('%')}{vm_parent}"
- "repos"
- "tlsdata"
- "users"
- "common"What are you seeing
puppet is issuing the following error:
Warning: /etc/puppetlabs/puppet/hiera.yaml: Use of 'hiera.yaml' version 3 is deprecated. It should be converted to version 5
(in /etc/puppetlabs/puppet/hiera.yaml)
What behaviour did you expect instead
as always, i would expect this to just magically work.
Any additional information you'd like to impart
…however, there's currently no documentation on hiera5: https://tickets.puppetlabs.com/browse/HI-555
With hiera 5 and just released PE2017.1 this module has run it's course, IMHO.
hiera 5 expects you to have hiera.yaml as part of an environment, which is usually deployed from a source code repository, so we will have to create it manually.
I agree that a lot of people will probably migrate their hiera.yaml into the control repo. But I think that this module can still be useful to manage the packages for different hiera backends and, maybe, manage the global configuration (to somehow have the same settings as production environment hiera.yaml)
This doesn't appear to be working for Hiera 5 from forge.puppetlabs.com:
mod 'puppet-hiera', '3.0.0'
Error: Could not retrieve catalog from remote server: Error 500 on SERVER: Server Error: Evaluation Error: Error while evaluating a Resource Statement, Evaluation Error: Error while evaluating a Resource Statement, Class[Hiera]:
has no parameter named 'hiera_version'
has no parameter named 'hiera5_defaults'
The repo seems to have the latest, though. Looks like it just hasn't been updated in the forge. The following may work in the interim:
mod 'puppet-hiera',
:git => 'https://github.com/voxpupuli/puppet-hiera.git',
:commit => '950acd2'
Install OK in PE 2017.2.1
Right, do not use this module. It will write >= v4 syntax to /etc/puppetlabs/puppet/hiera.yaml which will throw the following error when debugging:
/opt/puppetlabs/puppet/lib/ruby/vendor_ruby/hiera/config.rb:32:in `load': v4 hiera.yaml is only to be used inside an environment or a module and cannot be given to the global hiera (RuntimeError)
from /opt/puppetlabs/puppet/lib/ruby/vendor_ruby/hiera.rb:49:in `initialize'
from /usr/local/bin/hiera:232:in `new'
from /usr/local/bin/hiera:232:in `<main>'
hiera.yaml should be made part of the environment (i.e. control repository) and this module only be used to configure Hiera v3 syntax for backwards compatibility.
I think I'm in agreement. It was cleaner and faster for me to effectively rewrite ::hiera::install for PE2017.2 and just invoke it from my hiera profile. I'd be cautious about trying to become a hiera backend swiss-army knife. The module dependencies and configuration may start to become rather daunting since there is broader support for different backends now.
I stand corrected, there is still one important part to the module. Ensuring that the global hiera config isn't colliding with the environment definition and upgrading the current PE default from version 3 to version 5. That said, a simple check to see if the node name matches the puppetmaster name and then to replace the default hiera config isn't too bad.
AFAICS, this seems to be working since v3.1.0 release, more or less.
does that mean we can close this issue?
is the documentation updated, too?