Here's a simple example that works for me :- First you obviously have the ripienaar/module_data module installed and available to your puppet apply (I'm using masterless puppet).
My folder structure :- - puppet |---- modules |------- sonarqube |---------- data |------------- hiera.yaml |------------- common.yaml |------------- osfamily |---------------- windows.yaml |---------------- ubuntu.yaml |------------- version |---------------- 4.5.yaml |---------------- 5.0.yaml ..\puppet\modules\sonarqube\data\hiera.yaml :hierarchy: - "osfamily/%{::osfamily}" - "version/%{sonarqube::sonarqube_majmin_version}" - common :backends: - yaml :yaml: :datadir: puppet://sonarqube/data common.yaml :- sonarqube::sonar_runner_version: '2.4' sonarqube::sonar_runner_zip: "sonar-runner-dist-%{hiera('sonarqube::sonar_runner_version')}.zip" sonarqube::sonarqube_server_hostname: 'localhost' sonarqube::sonarqube_server_port: '9000' sonarqube::sonarqube_database_type: 'mysql' ... 4.5.yaml :- sonarqube::sonarqube_full_version: '4.5.2' sonarqube::sonarqube_installer_zip: "sonarqube-%{hiera('sonarqube::sonarqube_full_version')}.zip" ... windows.yaml :- sonarqube::sonarqube_package_location: 'C:/puppet-installs/sonarqube' sonarqube::sonarqube_apps_install_basefolder: 'C:/Apps' ... Then in ...\puppet\modules\profiles\manifests\sonarqube.pp (I'm following the roles and profiles pattern) :- class {'::sonarqube': #sonarqube_install_path => $sonarqube_install_path, #sonarqube_package_location => $sonarqube_package_location, #sonarqube_installer_zip => $sonarqube_installer_zip, sonarqube_majmin_version => $sonarqube_majmin_version, #sonar_runner_version => $sonar_runner_version, #sonarqube_proxy_host => $sonarqube_proxy_host, #sonarqube_proxy_port => $sonarqube_proxy_port ... } Now, how you set the values you passed to the parameterised class (::sonarqube) is up to you (note: do hiera lookups only in your PROFILE class). First you could set all/some of them explicitly either by simply assigning a literal or doing a hiera call (obviously the first option here takes hiera completely out of the equation since it has the highest precedence when resolving the class params) :- $sonarqube_server_port = '9000' or (given the above common.yaml) :- $sonarqube_majmin_version = hiera('sonarqube::sonarqube_server_port') You might take the view that you are only going to pass explicit values for those that you want to over-ride (i.e. all others will be resolved by automatic parameter lookup). Keep in mind that, resolution order in the target class is :- 1. Explict param value passed. 2. Automatic param lookup (Hiera ... which goes to SITE level hiera FIRST and then to MODULE level) 3. Default param value (I would recommend NOT doing that in most cases - better to catch config errors rather than the potential of a difficult to find false positive) 4. Error Not sure where your lookup is falling down, perhaps its resolution order (2) above ??? HTHs Fraser. On Tuesday, 24 March 2015 07:53:36 UTC, gregory...@calorieking.com wrote: > > I've been trying to use the module_data module, but cannot get it to > bring in values. Is there a worked example somewhere, including site.pp > and hiera.yaml? > > https://github.com/zipkid/puppet3-hiera_data_in_module hasn't helped - I > get the class defaults from init.pp, not the data from the yaml files. > > Cheers, > Greg. > -- You received this message because you are subscribed to the Google Groups "Puppet Users" group. To unsubscribe from this group and stop receiving emails from it, send an email to puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ab8d0a6d-424b-4333-8d6e-4d87662d94a3%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.