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, [email protected] 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 [email protected].
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.
