FAQ
That looks great.

Another thing to consider: As of hiera 1.2.0, you have deep merge for hashes.
You do not need to repeat parameters at every level !


“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)

----- Original Message -----
From: "Jonathan Proulx" <jon@jonproulx.com>
To: puppet-users@googlegroups.com
Sent: Monday, April 8, 2013 3:14:04 PM
Subject: Re: [Puppet Users] Not custom facts, but variables?


On Mon, Apr 8, 2013 at 2:57 PM, Dan White wrote:






Based on your description, I would suggest the following:

Let's take tomcat as a specific example.
Assumption: You have a tomcat module that can be configured with parameters.

Here is the suggestion: Add a hostname level to your heirarchy






but if you have multiple tomcat servers (for example) then you have to repeat data for each hostname which is exactly the wrong thing.


using a custom fact (I use "role" for essentially the same thing Tony wants to use "application for) you can classify nodes without an ENC and without repeating yourself.


My hierarchy is:
# cat /etc/puppet/hiera.yaml
---
:hierarchy:
- %{fqdn}
- %{role}
- %{group}
- %{osfamily}
- common
:backends:
- yaml
- puppet
:yaml:
:datadir: /etc/puppet/environments/%{environment}/data
:puppet:
:datasource: data


I do have fqdn, but that is always too specific, except maybe for testing. "Role" is what the system does and "group" is who manages it, both of these come form custom facts on the system in /etc/factor/facts.d (requires puppetlabs_stdlib) so I can have multiple nodes (in some cases hundreds) with the same role. Keying this off fqdn or cert name would me a nightmare


Picking the right hierarchy and the right level into to place data is a bit of a black art, but crucial to having a manageable config. This has been workable for me for the past 9 months or so, but not pretenses to perfection...



-Jon





<blockquote>


OK, so now for node hostx.example.org , you want this to be a tomcat server. All you need do is put the appropriate parameters into hostx.example.org.yaml

I am still a hiera n00b myself, so I am not totally sure exactly how to do this, but I am working on it.



“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)


From: "Tony C" < tonyjchong@gmail.com >
To: puppet-users@googlegroups.com
Sent: Monday, April 8, 2013 2:43:41 PM
Subject: Re: [Puppet Users] Not custom facts, but variables?



sure, to be specific,


we have environments, dev, test, qa, stage, and prod. That part I got with your help on my last post. Thank you.


Within these environments, we have applications. We only have a few apps. So let's say some machines are oracle db machines, some are tomcat, and some are apache.


I have yaml files for each, oracledb.yaml, tomcat.yaml, apache.yaml. Each of these yaml files contain some key value pair that is specific to that environment.


So when some machine is provisioned, I want to say this machine is a tomcat machine, and I don't care what environment it since I will let the agent conf figure that out. That way I can one puppet module for tomcat, but different values per environment.


I hope that makes sense, and if my approach is completely wrong, I'm open to hear some alternatives. Thanks again everyone.

--
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+unsubscribe@googlegroups.com .
To post to this group, send email to puppet-users@googlegroups.com .
Visit this group at http://groups.google.com/group/puppet-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .






--
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+unsubscribe@googlegroups.com .
To post to this group, send email to puppet-users@googlegroups.com .
Visit this group at http://groups.google.com/group/puppet-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .



</blockquote>



--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en .
For more options, visit https://groups.google.com/groups/opt_out .


--
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+unsubscribe@googlegroups.com.
To post to this group, send email to puppet-users@googlegroups.com.
Visit this group at http://groups.google.com/group/puppet-users?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.

Search Discussions

Discussion Posts

Previous

Follow ups

Related Discussions

Discussion Navigation
viewthread | post
posts ‹ prev | 7 of 13 | next ›
Discussion Overview
grouppuppet-users @
categoriespuppet
postedApr 8, '13 at 6:28p
activeApr 8, '13 at 8:18p
posts13
users3
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase