Ask Your Question
2

What's the best pattern to use a deeper hiera merge and get around automatic parameter lookup limitations?

asked 2015-06-19 15:11:54 -0600

rnelson0 gravatar image

As described at the bottom of the hiera lookup types page, there is a significant limitation with merge behavior: automatic parameter lookup will always perform a native lookup even if the :merge_behavior is deep or deeper (the older redmine ticket leads to HI-118 in Jira). This prevents me from relying on deeper merge to define mysql::server::override_options in two files, one at my puppet_role hierarchy level and additional values related to replication in the clientcert hierarchy. For instance:

#puppet_role/mysql.yaml
# Simplified - there are close to a dozen values in reality
---
mysql::server::override_options :
  'mysqld':
    bind-address             : '0.0.0.0'

#clientcert/hostname.yaml
---
mysql::server::override_options
    server-id                : 1
    auto-increment-increment : 2
    auto-increment-offset    : 1

This generates two vastly different results based on whether hiera is called with or without a hash lookup (APL does lookups without):

# Without hash
$ sudo hiera mysql::server::override_options environment=mysql puppet_role=mysql clientcert=hostname
{"mysqld"=>
  {"server-id"=>1, "auto-increment-increment"=>2, "auto-increment-offset"=>1}}

# With hash
$ sudo hiera -h mysql::server::override_options environment=mysql puppet_role=mysql clientcert=hostname
{"mysqld"=>
  {"bind-address"=>"0.0.0.0", "server-id"=>1, "auto-increment-increment"=>2, "auto-increment-offset"=>1}}

This presents a problem as my profile class is pretty simple:

class profile::mysql::server{
  # SELinux stuff
  # Firewall rule

  include ::mysql::server
  include ::mysql::server::backup
  include ::mysql::server::account_security
}

I rely on APL to provide the values I need to the class without specifying them via a lookup. I believe that I can replace the top include with:

class {'::mysql::server':
  override_options = hiera_hash('profile::mysql::server::override_options'),   # with resultant changes to hiera yaml
}

Any other class parameters should still be filled by APL per the documentation. I have two questions:

  1. Is my reading of the documentation correct, that parameters not provided in the resource declaration will be filled in by APL?
  2. Is this a good pattern? Before I rewrite the structure of the profile and get 6 months down the road, I'd like to know if there are any known issues with this pattern or other suggested patterns to use instead.

Thanks!

edit retag flag offensive close merge delete

1 Answer

Sort by ยป oldest newest most voted
0

answered 2015-06-19 15:41:26 -0600

WhatsARanjit gravatar image

You'll want to wrap the hiera_hash function into a profile:

https://gist.github.com/WhatsARanjit/...

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

2 followers

Stats

Asked: 2015-06-19 15:11:54 -0600

Seen: 1,398 times

Last updated: Jun 19 '15