On 30/04/15 09:30, jcbollinger wrote: > <trim of summary of heira lookups> > > Priority lookup is Hiera's focus and default, and automated data binding > uses that mode exclusively. If you want hash-merge lookup then you must > call hiera_hash() explicitly in your manifest. > > > John >
John,
Here's a simplified example of one of my issues. I'm using the Puppet
Labs MySQL module to mange the base configuration of a MySQL
master/slave pair (replication is setup manually after inital
provisioning). Our hiera config is set for deeper merges. The behavior
I expect is that I should be able to set common entries items for both
server's "mysql::server::override_options:" parameter hash at a lower
heira level and put the server specific override options at the host
specific level. However, how automatic data bindings work it only takes
the highest priority hash.
Example Config (this doesn't work as intended for automatic databindings):
site.pp:
node default {
hiera_include('classes')
}
hiera.yaml ('server_role' is a custom fact based on hostname):
---
:backends: yaml
:yaml:
:datadir: "/etc/puppet/environments/%{::environment}/hieradata"
:hierarchy:
- "%{::clientcert}"
- "%{::environment}-%{::server_role}"
- common
:merge_behavior: deeper
dev-db.yaml:
---
classes:
- mysql::server
mysql::server::remove_default_accounts: true
mysql::server::root_password: some_password
mysql::server::override_options:
mysqld:
default_storage_engine: InnoDB
innodb_file_per_table: 1
bind_address: 0.0.0.0
log_bin: mysql-bin
binlog_format: mixed
expire_logs_days: 2
datadir: /var/lib/mysql
innodb_flush_log_at_trx_commit: 1
sync_binlog: 1
max_connections: 2000
dev-db-01.mydomain.net.yaml:
---
mysql::server::override_options:
mysqld:
server_id: 1
dev-db-02.mydomain.net.yaml:
---
mysql::server::override_options:
mysqld:
server_id: 2
The above is what I would expect the deeper merge to work like and I
think the original poster has this same issue. But what I have to do is
duplicate the hash from "mysql::server::override_options:" into both
servers, as in my above example, the only setting that gets applied due
to the priority lookup without hash merging is the server ID.
Since it's the Official Puppet Labs MySQL module, I'm not going to go
and change every hash parameter in the module to a hash lookup function,
because it would probably break something else. So I deal with the work
around of unnecessary duplication of data in hiera and try to let
everyone I work with know of this limitation for hash lookups and
automatic data bindings when working with 3rd party modules.
We certainly can (and do) use an explicit hiera_hash() lookup in some of
our own internal modules, but this results in inconsistent behavior due
to the limitations of the automatic databindings. The hiera issue is
the only reference to it I could find when I first started looking into
what was going on and why I wasn't getting the results I expected. It's
even mentioned in the hiera documentation:
https://docs.puppetlabs.com/hiera/1/lookup_types.html#deep-merging-in-hiera--120
--
Joseph Swick <[email protected]>
Senior SaaS Operations Engineer
Meltwater Group
--
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/554261EA.1010901%40meltwater.com.
For more options, visit https://groups.google.com/d/optout.
signature.asc
Description: OpenPGP digital signature
