[colug-432] Puppet Foreman default environment

[Rick Hornsby]

> On May 14, 2015, at 10:27, Scott Merrill <skippy at skippy.net> wrote:
> 
> 
>> On May 14, 2015, at 11:18 AM, Rick Hornsby <richardjhornsby at gmail.com> wrote:
>> 
>> 
>>> On May 14, 2015, at 10:06, Scott Merrill <skippy at skippy.net> wrote:
>>> 
>>> I have no experience with Foreman, so can’t provide any real help there.
>> 
>> Curious what you're doing for an ENC?  Puppet enterprise or something else?
>> 
>> I'm futzing with Foreman because we may end up using Satellite 6 to manage the environment, which has some puppet components like Foreman baked(?) in.
>> 
> 
> We do use Puppet Enterprise, so we have the Puppet Dashboard, but we don’t use that to apply classes to our nodes.  The pointy-clicky nature of the Dashboard makes it hard to automate, impossible to version control, and generally takes too long.
> 
> We use Hiera to apply classes to our servers:
>   http://docs.puppetlabs.com/hiera/1/
> 
> Specifically, we rely on hiera_include:
>   http://docs.puppetlabs.com/hiera/1/puppet.html#assigning-classes-to-nodes-with-hiera-hierainclude
> 
> Our manifests/site.pp contains this line:
>   hiera_include('classes’)
> 
> We have a “classes” array in various Hiera files. For example, to apply our base profile to all servers, we have this in our hieradata/global.yaml:
> ---
> classes:
>  - profile::base
> 
> Additional classes can be applied at various other levels of our Hiera hierarchy, though mostly they’re set on a per-server level.


If I didn't mention this before - thank you for this explanation.  This has been a massive help and significantly shifted my thinking about how to manage the applied classes and class parameters.  It is much easier to understand what is happening by doing it this way.  The yaml files are far easier to read than puppet class files I was using.  I like using the yaml files to set the classes and parameters, and the .pp class files to write the actual puppet manifest code.  It also helps create a mental and contextual separation between the two.

I came back to this email to ask a question about managing what could easily be an out of control hiera.yaml hierarchy - but you answered the question already.

For now, I've landed on
- node/%{::fqdn}
- datacenter/{%::datacenter} # based on a custom fact
- common # what you called base

I think your comment about "mostly set on a per-server level" is what would keep the hierarchy from spinning wildly out of control.

-rj