Allow customizing module-layer Hiera configuration

[nabertrand]

This adds four new RSpec configuration parameters to modify the behavior of module-layer Hiera data.

• disable_module_hiera
  • Enabling this will prevent Puppet from using module-layer Hiera data entirely. This includes the module being tested as well as any fixture modules. The end effect is that only Hiera data from the global :hiera_config parameter will be used.
• use_fixture_spec_hiera
  • Enabling this will prevent Puppet from using the module-layer Hiera config file and instead search the module spec folder for a file named hiera.yaml.
• fallback_to_default_hiera
  • Controls whether or not to fall back to the default hiera.yaml file for the module layer if use_fixture_spec_hiera is enabled and no spec hiera.yaml file is found. Defaults to true.
• fixture_hiera_configs
  • A hash of module names and their respective module-layer Hiera config file paths. This can be used to override the path to the module-layer hiera.yaml.

The original impetus for creating these settings was to solve errors generated from modules that had eyaml enabled in their hiera config files. Even with :hiera_config set appropriately, Puppet would still try to load hiera data from the module layer. See #626.

If these settings seem useful for merging, I would be glad to update any appropriate documentation.

[coveralls]

Coverage increased (+0.2%) to 86.976% when pulling fc9960f on nabertrand:hiera into 6e6ebcf on rodjek:master.

[vStone]

Would it be possible to have use the fixtures/hiera.yaml and module hiera.yaml at the same time?

It would feel more natural if the fixtures/hiera.yaml acts as global or environment level hiera configuration

[nabertrand]

Would it be possible to have use the fixtures/hiera.yaml and module hiera.yaml at the same time?

It would feel more natural if the fixtures/hiera.yaml acts as global or environment level hiera configuration

I find myself easily confused when trying to describe the different hiera configs and layers involved when spec-testing a module. Perhaps a directory tree might help me better understand the concern, where test-module is the module being tested by rspec and fixture-module is a test dependency of test-module:

test-module/hiera.yaml
test-module/spec/fixtures/hiera.yaml
test-module/spec/fixtures/modules/fixture-module/hiera.yaml
test-module/spec/fixtures/modules/fixture-module/data/common.yaml
test-module/spec/fixtures/modules/fixture-module/spec/fixtures/hiera.yaml
test-module/spec/fixtures/modules/fixture-module/spec/fixtures/data/common.yaml

If you're asking about using test-module/hiera.yaml as the module-layer hiera config for test-module and test-module/spec/fixtures/hiera.yaml as the global-layer hiera config, then I believe that is how rspec-puppet always behaved by setting :hiera_config to spec/fixtures/hiera.yaml. Without this PR, setting :hiera_config has no effect on the module layer so Puppet continues to use the default location for module-layer hiera configs of each module, e.g. test-module/spec/fixtures/modules/fixture-module/hiera.yaml would be the module-layer hiera config location for fixture-module.

If you're asking about using test-module/spec/fixtures/modules/fixture-module/hiera.yaml as the module-layer config for fixture-module and still being able to have test-module/spec/fixtures/modules/fixture-module/spec/fixtures/hiera.yaml supercede values set in test-module/spec/fixtures/modules/fixture-module/hiera.yaml, the easiest solution I can see is referencing the module-layer hiera data in test-module/spec/fixtures/modules/fixture-module/spec/fixtures/hiera.yaml:

---
	version: 5
	defaults:
	  data_hash: yaml_data
	  datadir: data
	hierarchy:
	  - name: Production module data
	    path: ../../../data/common.yaml
	  - name: RSpec module data
	    path: common.yaml

Does that answer your question?

[rodjek]

@nabertrand Thanks for doing this. I'm more than happy to merge this in once the documentation has been updated. The new settings definitely need to be added to the configuration reference https://github.com/rodjek/rspec-puppet/blob/master/docs/documentation/configuration/index.md.

As you mentioned though, the interaction of the different hiera layers with spec testing can be a confusing subject, so maybe a bit of a long form explanation as an fragment in https://github.com/rodjek/rspec-puppet/tree/master/docs/_includes that can then be included in the "testing classes", "testing defined types" pages as well.

[sanfrancrisko]

#809 encompasses all of this work, in addition to updating the configuration documentation and resolving the merge conflicts on the branch.

[scotje]

Superseded by #809