Ask Your Question
0

Hiera hierarchy directory based on current module's directory

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

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)
  services/
  services/s_mysql
  services/s_mysql/manifests
  services/s_mysql/templates
  services/s_apache
  services/s_apache/manifests
  services/s_apache/templates
  ... 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

services/s_mysql/hieradata
services/s_apache/hieradata
... etc ...

where I would put the server-specific hiera data.

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

:hierarchy:
  - 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

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

How can I achieve this?

edit retag flag offensive close merge delete

Comments

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 -0500 )edit

Have you tried `%{module_name}` ?

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

1 Answer

Sort by ยป oldest newest most voted
1

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

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

Stats

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

Seen: 404 times

Last updated: Feb 16 '15