Ask Your Question

Hiera hierarchy directory based on current module's directory

asked 2015-02-12 11:30:31 -0600

Joseph Carlos gravatar image

We have a Puppet 3.7 installation. Out Puppet code is organized as follows:

  modules/ (shared Puppet code)
  manifests/ (site file)
  ... many more ....

All the MySQL server manifests are in services/s_mysql/manifests, all the Apache server manifests are in services/s_apache/manifests, etc.

I would like to start using hiera and create new directories like

... etc ...

where I would put the server-specific hiera data.

I could add each directory to the :hierarchy setting like so

  - services/s_mysql/hieradata
  - services/s_apache/hieradata
  - ... more ...
  - common

but this means every time I add a new class of servers, I have to update the :hierarchy setting.

I would like to do something like

  - "services/%{::some_puppet_variable}/hieradata"
  - common

How can I achieve this?

edit retag flag offensive close merge delete


Have you thought about setting a custom fact on each node and fill the `%{::some_puppet_variable}` dynamically?

kaizenCoder gravatar imagekaizenCoder ( 2015-02-15 20:28:29 -0600 )edit

Have you tried `%{module_name}` ?

Nick gravatar imageNick ( 2015-02-16 03:26:24 -0600 )edit

1 Answer

Sort by ยป oldest newest most voted

answered 2015-02-16 04:30:04 -0600

Nick gravatar image

%{module_name} (or maybe %{::module_name}) ought to work. Some people report having trouble with using it in Hiera, possibly due to it being a local variable rather than a global one,

Otherwise, you could come at it the other way like @kaizenCoder suggests. Rather than have the included module define the node's role, you could define a role some other way (setting a global variable; parsing the hostname; whatever you currently use to tell Puppet what counts as a MySQL server) and include facts based on that. At our place we parse the hostname into a role such as cms_app or mysql, then call hiera_include('classes'). The Hiera hierarchy checks our role variable, so we can then write a roles/mysql.yaml file containing an array called classes (a list of classes that will get included) plus any config data it may need.

This might be duplicating work for you since your service classes are already defining your role, which is perfectly fine. Give module_name a go to start with.

The original Hiera author has written this experimental module for storing Hiera data within a module - but it's designed more for third-party modules that want to distribute default data with their module. As you're in control of all your service modules and their layout, there's probably no need to use this.

edit flag offensive delete link more

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

Add Answer

Question Tools

1 follower


Asked: 2015-02-12 11:30:31 -0600

Seen: 554 times

Last updated: Feb 16 '15