docs: add tutorial for testing hiera data #762
Comments
|
Yes please. |
penguinspiral
added a commit
to penguinspiral/puppet-control-repo
that referenced
this issue
Dec 28, 2020
To satisfy Hiera lookups (as opposed to purely 'fact' based references) RSpec tests now have their own respective Hiera hierarchy defined at: 'site/profiles/fixtures/hiera.yaml'. All existing (and future) RSpec tests will now perform "Automatic Parameter Lookups" only falling back to in-class default values should the corresponding key not be found. The 'datadir' path to the RSpec test directory is relative to the 'Profiles' module's 'root' directory: 'site/profiles'. As of this commit the "data-in-module" pattern is not currently utilised and consequently dedicated RSpec specific Hiera data files are consumed. The 'ghoneycutt-ssh' community module utilises a deprecated Hiera function, 'hiera_hash', for performing a "deep" merge of an explicit key: 'ssh::keys'. This is addressed in the same manner as: c3a17e3e896ad24599d6f9274cc8f37a45844e41. Unfortunately Hiera v3 had to be adopted as the Ruby gem 'rspec-puppet' utilised by `pdk` is unable to parse Hiera v5 configuration file syntax. Related links regarding Hiera v3 & puppet-rspec limitations: * rodjek/rspec-puppet#762 * rodjek/rspec-puppet#551 * https://tickets.puppetlabs.com/browse/HI-598
penguinspiral
added a commit
to penguinspiral/puppet-control-repo
that referenced
this issue
Dec 29, 2020
To satisfy Hiera lookups (as opposed to purely 'fact' based references) RSpec tests now have their own respective Hiera hierarchy defined at: 'site/profiles/fixtures/hiera.yaml'. All existing (and future) RSpec tests will now perform "Automatic Parameter Lookups" only falling back to in-class default values should the corresponding key not be found. The 'datadir' path to the RSpec test directory is relative to the 'Profiles' module's 'root' directory: 'site/profiles'. As of this commit the "data-in-module" pattern is not currently utilised and consequently dedicated RSpec specific Hiera data files are consumed. The 'ghoneycutt-ssh' community module utilises a deprecated Hiera function, 'hiera_hash', for performing a "deep" merge of an explicit key: 'ssh::keys'. This is addressed in the same manner as: c3a17e3e896ad24599d6f9274cc8f37a45844e41. Unfortunately Hiera v3 had to be adopted as the Ruby gem 'rspec-puppet' utilised by `pdk` is unable to parse Hiera v5 configuration file syntax. Related links regarding Hiera v3 & puppet-rspec limitations: * rodjek/rspec-puppet#762 * rodjek/rspec-puppet#551 * https://tickets.puppetlabs.com/browse/HI-598
penguinspiral
added a commit
to penguinspiral/puppet-control-repo
that referenced
this issue
Jan 2, 2021
By design the SSH profile class, 'profiles::ssh', configures the OpenSSH server to accept public key authentication as the *only* mechanism for authentication. This constraint requires the user to provide either (or both) public key(s) or explicitly enable traditional password authentication. To satisfy Hiera lookups (as opposed to purely 'fact' based references) RSpec tests now have their own respective Hiera hierarchy defined at: 'site/profiles/fixtures/hiera.yaml'. All existing (and future) RSpec tests will now perform "Automatic Parameter Lookups" only falling back to in-class default values should the corresponding key not be found. The 'datadir' path to the RSpec test directory is relative to the 'Profiles' module's 'root' directory: 'site/profiles'. As of this commit the "data-in-module" pattern is not currently utilised for class default values and consequently dedicated RSpec specific Hiera data files are consumed. Unfortunately Hiera v3 had to be adopted as the Ruby gem 'rspec-puppet' utilised by `pdk` is unable to parse Hiera v5 configuration file syntax. Related links regarding Hiera v3 & puppet-rspec limitations: * rodjek/rspec-puppet#762 * rodjek/rspec-puppet#551 * https://tickets.puppetlabs.com/browse/HI-598
penguinspiral
added a commit
to penguinspiral/puppet-control-repo
that referenced
this issue
Jan 3, 2021
By design the SSH profile class, 'profiles::ssh', configures the OpenSSH server to accept public key authentication as the *only* mechanism for authentication. This constraint requires the user to provide either (or both) public key(s) or explicitly enable traditional password authentication. To satisfy Hiera lookups (as opposed to purely 'fact' based references) RSpec tests now have their own respective Hiera hierarchy defined at: 'site/profiles/fixtures/hiera.yaml'. All existing (and future) RSpec tests will now perform "Automatic Parameter Lookups" only falling back to in-class default values should the corresponding key not be found. The 'datadir' path to the RSpec test directory is relative to the 'Profiles' module's 'root' directory: 'site/profiles'. As of this commit the "data-in-module" pattern is not currently utilised for class default values and consequently dedicated RSpec specific Hiera data files are consumed. Unfortunately Hiera v3 had to be adopted as the Ruby gem 'rspec-puppet' utilised by `pdk` is unable to parse Hiera v5 configuration file syntax. Related links regarding Hiera v3 & puppet-rspec limitations: * rodjek/rspec-puppet#762 * rodjek/rspec-puppet#551 * https://tickets.puppetlabs.com/browse/HI-598
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Inspired by #601 it would be helpful to have another tile on this page http://rspec-puppet.com/documentation/ for testing modules using hiera data.
I'm using PDK, and sadly quite a lot of material that can be found online is for ancient versions of Puppet and/or hiera, old ways of using rspec in combination with various other gems, and even just lots of copy/paste code, and thus i'm really missing some authoritative pointers as to what and how I ought to test my modules that are getting/looking up data from hiera.
Observation: If I don't specify any
hiera_configin the rspec configuration, then the module's "normal" hiera data is the only thing that is used, as defined bymy_module/hiera.yamlconfiguration.Being new to ruby and rspec, having read the "Why should you test your Puppet modules?
" part of the tutorial, that surprised me. I was not expecting rspec to use any of my modules hiera data.
I was expecting to have to define my own simplified hiera data inside the
my_module/spec/folder, such that when my modules hiera data changed, my rspec data would stay the same and not be subject to any refactoring changes/erros.Reading #732 just makes me even more confused as to what the correct way of testing hiera data is. This PR adds parameters to disable the modules normal hiera data, and any combination in between.
Also notes about how to deal with modules that are using eyaml would be nice.
This subject seems partially discussed in #626.
Anothing that would be nice to have in the README.md#hiera_config, is that it only supports hiera v3 configurations. The example later on at README.md#hiera-integration, clearly uses v3 syntax, but it doesnt state anything about it, so I thought it was an old exmaple that hadn't been updated.
I wasted a good day of my life trying to figure out why it didn't use my hiera data specified in my
my_module/spec/spec_helper_local.rb. It became clear why, after reading this: HI-598. Sadly I didn't get any error when runningpdk test unitorbundle exec rake spec, but converting mymy_module/spec/hiera.yamlfrom version 5 til version 3 made it work right away.This also seems to be partially discussed in #551.
The text was updated successfully, but these errors were encountered: