[Puppet Users] Resource ordering only using Hiera?
Hello,
I'm trying to come up with a generic wrapper class for use with hiera so
that I can have a service that is completely managed and configured via
hiera and its own puppet module to be notified by Puppet of changes to a
file or other resource managed by a different class/module. The example
I'm using here is the management of /etc/security/limits.conf for a
service account that only needs to be changed on certain systems.
[Yes, I could put the configuration of the limits.conf into the module
for this particular service, but I'm trying to keep the dependencies of
that module to a minimum so that it is portable.]
Picture the following yaml hiera data for a node (the basic::limits
class is a wrapper for the puppet-limits module):
---
classes:
- foo
- basic::limits
foo::option_1: true
basic::limits::instance:
foo_limits:
user: 'foobar'
limit_type: 'nofile'
hard: '1'
soft: '1'
If I create a separate class, I can do the resource ordering normally as
expected:
class tmp {
Limits::Limits['foo_limits'] ~> Service['foo']
}
This separate class ensures that changes to the limits configuration
properly notifies the service to restart. However, I don't want to
clutter up our puppet configuration with a lot of singular
modules/classes just for resource ordering and would like to be able to
define it just in hiera. Therefore, I attempted to create a generic
wrapper define for resource ordering (the following doesn't actually
work, will get to the error):
#Define for resource ordering or subscribing
define basic::order_resource::ordering (
$resource1_type = undef,
$resource1_name = undef,
$resource2_type = undef,
$resource2_name = undef,
$notify = false,
){
if $notify {
$resource1_type[$resource1_name] ~> $resource2_type[$resource2_name]
} else {
$resource1_type[$resource1_name] -> $resource2_type[$resource2_name]
}
}
And a wrapper class to use it via hiera:
#basic::order_resource
class basic::order_resource ($instance){
$real_instance = hiera_hash(basic::order_resource::instance)
create_resources(basic::order_resource::ordering, $real_instance)
}
Sample yaml in hieradata:
basic::order_resource::instance:
foo_limits_sub:
resource1_type: Limits::Limits
resource1_name: foo_limits
resource2_type: Service
resource2_name: foo
notify: true
However, as I already stated, my generic define doesn't actually work
and returns the following error because Puppet can't/doesn't evaluate
the variable as an actual resource type:
Error: Could not retrieve catalog from remote server: Error 400 on
SERVER: resource1_type is not a hash or array when accessing it with
foo_limits at
/etc/puppet/modules/basic/manifests/order_resource/ordering.pp:10 on
node vagrant-centos-6
What am I missing to get Puppet to evaluate the $resourceX_type
variables as a resource type [e.g: File, Service, etc.] to get this to
work? I'd like to try do it this way so that I don't have to make a
very long, messy and hard to maintain class with a lot of nested case
statements to perform a similar function. That is, unless there's some
other method that I haven't considered/found/thought of.
sample nested case code (this will get ugly fast and isn't very flexible):
case $resource1_type {
'File': {
case $resource2_type {
'Service': {
if $notify {
File[$resource1_name] ~> Service[$resource2_name]
} else {
File[$resource1_name] -> Service[$resource2_name]
}
}
default: {fail("Unknown resource type '${resource2_type}' for
\$resource2_type")}
}
}
default: {fail("Unknown resource type '${resource1_type}' for
\$resource1_type")}
}
Thank you for taking the time to wade through my lengthy question.
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Re: Resource ordering only using Hiera?
On 12/16/2013 10:59 AM, jcbollinger wrote: > > > On Friday, December 13, 2013 3:56:50 PM UTC-6, Joseph Swick wrote: > > [...] > > What am I missing to get Puppet to evaluate the $resourceX_type >> variables as a resource type [e.g: File, Service, etc.] to get this to >> work? > > > > Puppet DSL does not provide such a feature. It is conceivable -- likely, > even -- that you could instead create a custom function to apply generic > ordering constraints such as you want but you should beware that unlike > relationships declared via the DSL, relationships applied via a function > would probably be sensitive to manifest evaluation order. > > >>> > > I suspect that the use case for the functionality you describe is not > nearly so general as you suppose. Module portability is more typically > approached in Puppet by using facts -- custom facts, if necessary -- to > probe the relevant characteristics of the target machine, and by using a > small number of higher-level alternatives to determine what to declare. > For example, it is common to use the $::osfamily fact to guide what > declarations to make, coding appropriate specifics for each supported OS > family. > > > John > Thank you for the reply. However, I think you may not be fully understanding what I was trying to describe (or I didn't describe it well enough). What I'm trying to do has nothing do do with resource facts on the system within a module. We're already using various facts to define which portions of the hieradata should be considered for a particular node. I would like to ensure that the resources that get defined as a result are created in the correct order when required. Tl;dr;: I'm looking to see if I can achieve resource chaining wholly within hiera definitions without having to create singular manifests/classes for nodes to include via hiera, which the sole purpose is to order resources that are being realized and configured via hiera. It's quite likely what I'm trying to achieve isn't currently possible in Puppet, but I was hoping that someone could point out something I overlooked. If not, I'll have to find an appropriate place in our puppet site to create the resource ordering classes for various nodes where the order of resource creation is critical. Thank you. -- Joseph Swick Operations Engineer Meltwater Group signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Roles/profile design
On 12/23/2013 02:52 PM, Josh wrote:
> Ramin,
>
> After looking more at your example for configuring apache mods via hiera, I
> have one problem.
>
> The create_resources will actually just define a resource like so:
>
> apache::mod { 'php' }
>
> However, to install the php module with puppetlabs/apache, I actually need
> to include the apache::mod::php class, ie:
>
> class { 'apache::mod::php' }
>
> Any ideas on how to make this work correctly? The hiera data should allow
> me to choose which apache::mod::subclass modules that should be installed.
>
> Thanks,
>
> Josh
>
Hi,
How are you declaring your classes to include from with in hiera?
Is it similar to this?
---
classes:
- apache
- apache::mod
apache::someparamater: value
apache::mod::php: blah
If so, you should be able to do:
---
classes:
- apache
- apache::mod::php
apache::my_favorite_parameter: value
apache::mod::php::php_parameter: some_other_vaule
I haven't tried that exact thing with the apache module, but it does
work for other modules with sub-classes that I've been working with.
That is assuming that you're using the 'classes' array with the
hiera_include function. We use the create_resources function to create
wrappers for defines, while regular classes are included via the
hiera_include and classes array.
Our setup was pretty much taken directly from the hiera documentation:
http://docs.puppetlabs.com/hiera/1/puppet.html#assigning-classes-to-nodes-with-hiera-hierainclude
There are some gotchas that come up with the hiera merge behavior
depending on how complex you're hiera layout becomes. For example, we
had to set the hiera merge_behavior to deeper for us to get some of the
desired results that we were looking for.
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Roles/profile design
On 12/26/2013 12:48 PM, Josh wrote:
> Joseph,
>
> So, the problem with this method appears to be that once you specify
> "hiera_include('classes')" in the environment's site.pp, Puppet appears to
> try and make Hiera the ONLY source for node classification. I rely on
> roles from my ENC and profiles for classification as well.
>
> Josh
>
That's certainly another gotcha with hiera and classes that's good to
know. We went to using hiera exclusively for our node classification,
so we didn't run into that issue as we're not using any other ENCs with
our current configuration.
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Re: Run stages of virtual resources
On 01/02/2014 03:18 AM, james.eckers...@fasthosts.com wrote: > How about chaining the resources, ala > http://docs.puppetlabs.com/puppet/2.7/reference/lang_relationships.html#chaining-arrows > . > > Yumrepo <| |> -> Package<| |> > > This declared in site.pp should apply globally to all nodes and would avoid > the use of run stages (if I understand it correctly). > > J > One caveat to this is that if you are defining any packages (or the YumRepos) virtually and then adding them to modules with 'realize', the resource collector will realize all of the virtual packages, regardless whether if you're realizing them in a module or not. This behavior is documented in the resource chaining documentation. I ran into this personally with a couple of custom modules that we use virtual packages with so that we don't get duplicate resource errors when managing various packages. My case was very similar, I had a custom Yum repo I wanted to ensure that was put in place before puppet tried to install a package out of it, so I had defined the chaining within the module for the yum repo of: Yumrepo['CustomRepo'] -> Package <| name == 'CustomPackage' |> However, when I moved the custom package into our virtual package resources, that package started getting realized on machines that didn't need it, but I had forgotten that I had done the above resource chaining. Fortunately, we did provide a way to require repos with our virtual package definitions, so I was able to remove the resource chaining and still have the desired result. -- Joseph Swick Operations Engineer Meltwater Group signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Notify service in one class from other class
On 01/13/2014 08:51 AM, Denis Kot wrote:
> I have the following classes:
>
> node 'prerun' {
> ...
>class {'zabbix-agent': stage => pre}
> ...
> }
>
> but that code produces error:
>
> err: Could not apply complete catalog: Found dependency cycles in the
> following relationships: Service[zabbix-agent] =>
>
> what's wrong? if I comment out 'notify' puppet doesn't complain, but
> doesn't restart service too.
>
From my quick look at it, it would appear that your 'pre' stage is the
cause of it. Judging by it's name, I'm assuming you have a
stage { 'pre': before => Stage['main'] }
Somewhere in your manifiests?
I've found that stages are very finicky about the order of items,
especially when doing relationships between items in different stages.
I try to avoid stages whenever possible and do resource ordering within
the main puppet stage to ensure items are created in the correct order.
The few places I do use stages, I have them run after main and I'll
eventually work to remove them.
Have you tried running it without the stage?
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Title on file resources
On 01/14/2014 05:12 PM, Justin Lambert wrote:
> I’m attempting to create a bunch of symlinks based on an array of filenames
> but I can’t figure out how to use the title of the resource within the
> resource itself.
>
> class app::config {
> file { [ 'a.conf', 'b.conf' ]:
> ensure => 'link',
> path => "/etc/app/${name}",
> target => "/usr/app/${name}
> }
> }
> $name and $title both equal app::config in this example. Is what I’m trying
> to do possible?
>
> I’m running puppet 3.4.0.
>
> Thanks,
> Justin
>
It is, but you have to use a define (or at least how I'm doing it uses a
define), here's an example based on something thing I'm doing:
common.pp:
class my_module::common () {
...
my_module::common::my_symlinks { ['file1', 'file2', 'file3']: }
...
}
common/my_symlinks.pp:
define my_module::common::my_symlinks: {
file { "symlink_${name}":
ensure => link,
path=> "/some/path/${name}",
target => "/some/other/path/${name}",
}
}
I wasn't the first to figure that out, I think I remember who I got it
from, but I'm not sure if it's something they came up with or if they
got it from somewhere else. Hope that helps.
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Puppet manage HOMES on Desktop Computers
On 02/10/2014 09:15 AM, Rafael Cristaldo wrote:
> Hi All!
>
> Has anybody already needed to manage HOMES on desktops computers with
> puppet ?
>
> I have create a class to manage the /etc/skel directory...so the problem is
> that after thet the user loggin ... the home has been created em copied all
> /etc/skel files..
>
> But NOW i need to put another LINK for exemplo
>
> The class create the new LINK at /etc/skel ...but how to create the link
> into /home/$USER ??
>
> This works fine..but how to create this like a class in PUPPET?
>
> Thanks!!
>
I'm not sure if our use case is similar to yours or not. However, I
added the following to our user management module to ensure that the
user's home directory regardless of how it's created or managed, has all
the appropriate files from the local system's /etc/skel. The 'touch
/dev/null' is so that don't have to do "provider => 'shell'," in the
exec (which we had a reason for at the time, but I'm not recalling it
right now):
#Copy base profile from /etc/skel, update only but make backup if we
happen to overwrite an existing file
#Made as portable as possible because CentOS 5 doesn't support the
'-n' option for cp.
exec {"${username}_copy_skel":
command => "touch /dev/null; for i in `ls -A /etc/skel`; do /bin/cp
-R -u --backup=numbered /etc/skel/\$i ${homedir_real}; done; /bin/chown
-R ${username}:${username} ${homedir_real}",
unless => "test \"\$(j=0;for i in `ls -A /etc/skel`; do test -e
${homedir_real}/\$i; if [ \"\$?\" -ne \"0\" ]; then j=1;fi; done;echo
\$j)\" = \"0\"",
}
It may not be all that efficient for a system that has a lot of users on
it. Hope that helps.
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Re: Puppet manage HOMES on Desktop Computers
On 02/10/2014 12:09 PM, Rafael Cristaldo wrote:
> Hi Joseph Swick !
>
> Thanks for the answer !
>
> This really can help me! .. but thereis some questions about your manifest.
>
> Did you build custom factes for ${username} and ${homedir_real} ? Or you
> propose to edit it and change this values to the real Username and Homdir ?
Sorry, I should have pointed out that those are parameters/variables in
our custom module. For $homedir_real, it takes homedir as an optional
parameter, if it's not set, then it uses a default based on the
username, then assigns it to $homedir_real. If $homedir is set, then it
gets assigned to $homedir_real.
For $username, that's taken from the title of the define for actually
creating the users in our user management module as we're managing users
from within Puppet. After re-reading your original message, I noticed
that you stated you're managing users from LDAP, so I'm not sure if this
is something you could easily incorporate into puppet to take care of,
unless it's a custom script that you push out via puppet and create a
cronjob for.
> This is really a very valid option to keep both directories (/etc/skel and
> /home/USER) with same files...but it does not REMOVE files from the HOME
> directory that i don't need anymore, just remove from /etc/skel
Unfortunately no, it won't clean up anything that's been removed from
/etc/skel, only update user's home directories with new items in there.
But that's likely due to our different use case.
> Anyway thanks for your help.
>
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] puppet 3.4: N00b has Trouble with regexes in a if-else structure manifest config.pp
On 02/10/2014 03:36 PM, notify.s...@gmail.com wrote:
> Hi
>
> I'm probably doing something horribly wrong. I can sense it, but it hasn't
> properly kicked in yet...
>
> I'm trying to create a module for iptables. This is to make servers that
> have similar purpose, have the same flrewall configuration.
> I created the modules/iptables/{manifests,files,templates} structure, Iike
> I have for a few modules I have been able to put together.
Out of (a possibly morbid) curiosity, have you looked at the
Puppetlabs-firewall module? It may already do some of the things that
you're trying to do (with regards to managing iptables). At first
glance, it would seem that you maybe trying to reinvent work that other
people have already solved.
https://github.com/puppetlabs/puppetlabs-firewall
> For some reason puppet claims not to see the iptables:::config class, which
> I have tried to setup in multiple ways, using regexes.
> Configuration is like so:
>
> class iptables::config {
>
>
> The agents all cry "Could not retrieve catalog from remote server: Error
> 400 on SERVER: Could not find class iptables::config for myname on node me"
Is the file containing iptables::config in the appropriate directory and
named properly? E.g: modules/iptables/manifests/config.pp ?
> Please can some kind person show a poor little beginner what I am doing
> wrong?
>
> Thanks!
>
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Managing iptables with puppet
On 03/12/2014 06:13 AM, Sandro von Matterhorn wrote: > > > Hello Community, > > we are managing 40 Linux Servers with Puppet and it is really a great tool. > > But now we want to configure our firewall settings via Puppet and I am > searching for an elegant way to do this. > > > But this is to static. I don't want to allow generally Port 443 for example > (this would work with this template), I want a solution for IP + Port Pairs. > Does anybody has an idea, how I could do this? > > > Thanks a lot > Have you looked at the PuppetLabs Firewall module from the forge yet? It can do most (if not all) of what you're trying to do for iptables management with manifests. http://forge.puppetlabs.com/puppetlabs/firewall -- Joseph Swick Operations Engineer Meltwater Group signature.asc Description: OpenPGP digital signature
[Puppet Users] Package Resource, Versioning and Yum
Hi list,
I'm working on a little addition to an internal module we use to ensure
our puppet clients have a consistent configuration to also ensure the
correct version of puppet is installed on the system and run into a bit
of semantics issue as I thought that "ensure => 'version.num'" was a
more correct way of specifying the version of a package, rather than
doing it in the name of the resource.
Here's a few snippets of code:
Common class opening:
class puppet_mw::client (
...
$manage_versions = true,
$puppet_version = '3.6.2',
$facter_version = '2.0.2',
$hiera_version= '1.3.4',
...
) {
This works:
if $manage_versions {
package { "puppet-${puppet_version}":
ensure => present,
}
package { "facter-${facter_version}":
ensure => present,
}
package { "hiera-${hiera_version}":
ensure => present,
}
}
This however, does not:
if $manage_versions {
package { 'puppet':
ensure => ${puppet_version},
}
package { 'facter':
ensure => ${facter_version},
}
package { 'hiera':
ensure => ${hiera_version},
}
}
As it generates this error:
Error: Could not update: Failed to update to version 3.6.2, got version
3.6.2-1.el6 instead
Wrapped exception:
Failed to update to version 3.6.2, got version 3.6.2-1.el6 instead
Error: /Stage[main]/Puppet_mw::Client/Package[puppet]/ensure: change
from 3.6.2-1.el6 to 3.6.2 failed: Could not update: Failed to update to
version 3.6.2, got version 3.6.2-1.el6 instead
Error: Could not update: Failed to update to version 2.0.2, got version
2.0.2-1.el6 instead
Wrapped exception:
Failed to update to version 2.0.2, got version 2.0.2-1.el6 instead
Error: /Stage[main]/Puppet_mw::Client/Package[facter]/ensure: change
from 1.7.5-1.el6 to 2.0.2 failed: Could not update: Failed to update to
version 2.0.2, got version 2.0.2-1.el6 instead
Error: Could not update: Failed to update to version 1.3.4, got version
1.3.4-1.el6 instead
Wrapped exception:
Failed to update to version 1.3.4, got version 1.3.4-1.el6 instead
Error: /Stage[main]/Puppet_mw::Client/Package[hiera]/ensure: change from
1.3.2-1.el6 to 1.3.4 failed: Could not update: Failed to update to
version 1.3.4, got version 1.3.4-1.el6 instead
Which lead me to this, but will get messy to ensure compatibility with
different Linux versions:
if $manage_versions {
case $::osfamily {
'RedHat': { $os_string = "-1.el${::operatingsystemmajrelease}" }
default : { $os_string = undef }
}
package { 'puppet':
ensure => "${puppet_version}${os_string}",
}
package { 'facter':
ensure => "${facter_version}${os_string}",
}
package { 'hiera':
ensure => "${hiera_version}${os_string}",
}
}
Running 'yum install puppet-3.6.2' works as desired, but adding
'allow_virutal => true,' to the package resource doesn't change the
previous error.
Is this working as designed for the Yum provider for the package
resource or is this a bug with the provider? For some reason, I want to
think this has been discussed on the list before, but couldn't find the
relevant thread.
It appears I may be running up against this bug:
https://tickets.puppetlabs.com/browse/PUP-1244
TIA.
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Package Resource, Versioning and Yum
On 17/06/14 07:41, Jason Antman wrote: > Joseph, > > See https://tickets.puppetlabs.com/browse/PUP-682 > > I'm going to try and get the pull request rebased, but at best this will > be in puppet4. > > -Jason > Thank you, I had come across that bug report as well later on. I wasn't sure originally if this was a known issue or not. We'll see what presents Puppet 4 brings us. -- Joseph Swick Operations Engineer Meltwater Group signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Re: "require" broken with create_resources() ?
On 20/08/14 09:50, Vincent Miszczak wrote:
>
> Instead, I pass a YAML hash through an ENC (Foreman to be precise):
> test:
> url: "https://mygitrepos/myapp.git";
> root:"/opt/apps/myapp"
> user: root
> require: Class[myclass]
>
>
> I finally understand this won't work because this is expanded to
> require=>"Class[myclass]" instead of require=>Class[myclass].
> I was mislead by the error message that does not have any quote to
> distinguish strings from the rest.
>
I wonder if this is a limitation of Foreman or how Foreman is passing
the hash to Puppet? As I'm doing something similar to this in yaml with
hiera:
classes:
- basic::directory
- myservice
basic::directory::instance:
'/data/myservice/':
owner: svc_account
group: svc_account
mode: '0755'
require: Package[myservice]
before: Service[myservice]
myservice::data_dir: /data/myservice
The basic::directory class is a simple wrapper around create_resources
for the file resource.
class basic::directory ($instance){
$real_instance = hiera_hash(basic::directory::instance)
$defaults = {
'ensure' => 'directory',
'mode' => '0755',
'owner' => 'root',
'group' => 'root',
}
create_resources(file, $real_instance, $defaults)
}
The 'myservice' class handles the installation and management of the
service. In it the package is an RPM that creates the user account for
the service to run under, so the account doesn't exist until the package
is installed. However, the directory needs to be created with the
correct ownership and permissions before the service is started, as it's
been configured not to use the default directory.
This worked as desired when I first did it and I haven't seen any
errors. However, from reading the other comments in the thread, maybe
it shouldn't work?
--
Joseph Swick
Operations Engineer
Meltwater Group
signature.asc
Description: OpenPGP digital signature
Re: [Puppet Users] Hiera Hash Merge - Avoiding Duplicating
On 29/04/15 08:30, Dan White wrote: > Have you tried plain YAML ? > Your code looks OK, but I cannot be certain without tinkering. My initial > thought is that the eyaml backend may be to blame. So this is an issue I've run into on a couple of machines. As far as I can tell, it's not eyaml, I found this reference to the issue with relation to the automatic data bindings for hiera and hash merging: https://tickets.puppetlabs.com/browse/HI-118 It's been a bit of an issue for a couple of machines for us. As far as I've been able to tell, for where we do an actual heira lookup call it's not affected, just for automatic bindings to parameters. > "Sometimes I think the surest sign that intelligent life exists elsewhere in > the universe is that none of it has tried to contact us." > Bill Waterson (Calvin & Hobbes) > >> On Apr 29, 2015, at 5:39 AM, Dan Gibbons wrote: >> >> Hi, >> >> I'm just starting to use create_resources and hash merging which I have >> working but I'm not sure how I can avoid duplicating some of the hash values >> further up in the hierarchy. >> -- Joseph Swick 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/5540DBAD.4050700%40meltwater.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
Re: [Puppet Users] Hiera Hash Merge - Avoiding Duplicating
On 30/04/15 09:30, jcbollinger wrote:
>
>
> 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
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 puppet-users+unsubscr...@googlegroups.com.
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
Re: [Puppet Users] Hiera Hash Merge - Avoiding Duplicating
On 01/05/15 09:40, jcbollinger wrote: > On Thursday, April 30, 2015 at 12:10:19 PM UTC-5, Joseph Swick wrote: >> 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 >> >> >> > > I'm not sure what you're trying to say there. Yes, hash-merge behavior is > described in the hiera docs. That's relevant when you request a hash-merge > lookup. Not so much when you request a priority lookup, whether explicitly > or implicitly. > My issue is that as more module support the passing of custom parameters via a hash that people populate with Heira lookups (regardless of storage backend), they're going to be running into this issue even more and wondering why things don't work the way they expect they should. Perhaps the additional information that automatic data bindings with heira and puppet modules is priory only needs to be explicitly stated that it won't merge any hashes. Because, the docs imply that merges would happen with hashes (when they obviously don't). To me there is a disconnect between the documentation of heira lookups with the function calls and the automatic data binding feature of heira. In my organization, I'm not the only one who's gotten burned by the difference in merge behavior from the automatic data bindings. Those two pages I linked two have been the only documentation I've been able to find to pass on to people internally when they come across the problem. -- Joseph Swick 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/55477C5A.3000709%40meltwater.com. For more options, visit https://groups.google.com/d/optout. signature.asc Description: OpenPGP digital signature
