Dynamic Environments and Hiera

[Brad Ison]

Hi,

I've been using dynamic environments, one per Git branch, similar to
what's described here:

http://puppetlabs.com/blog/git-workflow-and-puppet-environments/

I've come to really like that workflow, but I'm struggling with how
best to integrate it with Hiera. In addition to short lived dynamic
branches, I'll have some longer lived ones that feed into master
(production), e.g. staging, dev, etc.

My hierarchy has traditionally looked something like this:

- 'environments/%{environment}/%{location}',
- 'environments/%{environment}',
- 'global'

What's the best way of having new environments pick data from the
right spot in the hierarchy without having to cram everything into the
global / common root?

For example, if I branch off of dev, creating a new environment called
'new_feature', only 'global' would be in scope unless I explicitly
copy the dev data to 'new_feature.yaml', which feels wrong.


Am I approaching this all wrong? Any advice?

--
Thanks,
Brad

[Luke Bigum]

Hi Brad,

On Tuesday, January 8, 2013 10:30:11 PM UTC, Brad Ison wrote:

Hi,

I've been using dynamic environments, one per Git branch, similar to
what's described here:

  http://puppetlabs.com/blog/git-workflow-and-puppet-environments/

I've come to really like that workflow, but I'm struggling with how
best to integrate it with Hiera. In addition to short lived dynamic
branches, I'll have some longer lived ones that feed into master
(production), e.g. staging, dev, etc.

I am using the very same workflow.

 

My hierarchy has traditionally looked something like this:

  - 'environments/%{environment}/%{location}',
  - 'environments/%{environment}',
  - 'global'

What's the best way of having new environments pick data from the
right spot in the hierarchy without having to cram everything into the
global / common root?

Your hierarchy data store is outside your environment, here is what mine looks like:

:backends:

  - yaml

:hierarchy:

  - %{fqdn}

  - %{role}_role

  - %{pop}

  - global

:yaml:

  :datadir: /etc/puppet/environments/%{environment}/hiera/

So if I push a new feature to branch new_feature, I get Puppet environment "new_feature" which has it's own copy of the Hiera data store with all my new_feature related Hiera keys in it. When it comes to environments my data follows the same branches and "versions" of my code, and when I merge code into my main line production branch the matching Hiera keys go along with it.

Hope that helps,

-Luke

[Brad Ison]

On Wed, Jan 9, 2013 at 3:11 AM, Luke Bigum <Luke....@lmax.com> wrote:
>
> :backends:
> - yaml
> :hierarchy:
> - %{fqdn}
> - %{role}_role
> - %{pop}
> - global
> :yaml:
> :datadir: /etc/puppet/environments/%{environment}/hiera/
>
> So if I push a new feature to branch new_feature, I get Puppet environment
> "new_feature" which has it's own copy of the Hiera data store with all my
> new_feature related Hiera keys in it. When it comes to environments my data
> follows the same branches and "versions" of my code, and when I merge code
> into my main line production branch the matching Hiera keys go along with
> it.

Thanks, Luke.

I guess it does make sense to leave the environments out of the
hierarchy in this case. I had considered that, but was worried about
constant merge conflicts when promoting things up the chain. There
will be some things that will always be different between dev and
prod. I suppose there are other ways around that though that make more
sense. I may be inventing a problem I don't really have.

--
Brad

[Erik Dalén]

I also use one environment per git branch. But I use a custom fact that returns production/testing etc and then use that in the hiera hierarchy instead of the puppet environment.

--
You received this message because you are subscribed to the Google Groups "Puppet Users" group.
To post to this group, send email to puppet...@googlegroups.com.
To unsubscribe from this group, send email to puppet-users...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.

[Brad Ison]

On Fri, Jan 11, 2013 at 12:10 PM, Erik Dalén
<erik.gus...@gmail.com> wrote:
> I also use one environment per git branch. But I use a custom fact that
> returns production/testing etc and then use that in the hiera hierarchy
> instead of the puppet environment.

That's actually along the lines of what I was thinking originally. One
Puppet environment per branch, remove the Puppet environment from the
Hiera hierarchy, and have my ENC tag machines with which Hiera
"environment" to use.

Makes sense. Thanks!

--
Brad

[Andreas Dvorak]

Hi,

today I started working with roles in hiera, but somewhere must be something wrong. In my test I would like to install a special version of facter on the server vm6740 that does belong to my test role, but it is installed the version from the common.yaml

cat hiera.yaml
---
:backends: yaml
:yaml:
  :datadir: /data/git/test/hiera
:hierarchy:
  - %{hostname}
  - %{role}_role
  - common
:logger: console

cat vm6740.yaml
---
role: "test"

cat test_role.yaml
---
facter::version: "2.3.0-1"

cat common.yaml
---
facter::version: "2.1.0-1"

Andreas

[Jeremy T. Bouse]

As far as I'm aware hiera is not going to go look back at itself in
this case and actually pick up the new hierarchy.

Instead you're going to have to set a custom fact on the host in
question that sets "role" to "test" and then it should be
able to be picked up. Also I believe you're going to need to prefact
those with facts with '::'.

I use a directory hierarchy so I actually have:

:hierarchy:
- "host/%{::clientcert}"
- "role/%{::role}"
- "virtual/%{::virtual}"
- "osfamily/%{::osfamily}"
- "domain/%{::domain}"
- "env/%{::environment}"
- common

> --
> 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...@googlegroups.com [1].
> To view this discussion on the web visit
>
> https://groups.google.com/d/msgid/puppet-users/cb539ce7-daa7-4421-bc26-e772ccdbf3ed%40googlegroups.com
> [2].
> For more options, visit https://groups.google.com/d/optout [3].
>
>
> Links:
> ------
> [1] mailto:puppet-users...@googlegroups.com
> [2]
>
> https://groups.google.com/d/msgid/puppet-users/cb539ce7-daa7-4421-bc26-e772ccdbf3ed%40googlegroups.com?utm_medium=email&utm_source=footer
> [3] https://groups.google.com/d/optout

[Andreas Dvorak]

Thank you for the information. Now I have got a solution.

class facts::app_fact(
  $app = hiera('app_fact',undef)
){
  file{'/etc/facter':
    ensure => directory,
    owner  => 'root',
    group  => 'root',
    mode   => '0755',
  }
  file{'/etc/facter/facts.d':
    ensure  => directory,
    owner   => 'root',
    group   => 'root',
    mode    => '0755',
    require => File['/etc/facter'],
  }
  if $app != undef {
    file{'/etc/facter/facts.d/app.txt':
      ensure  => file,
      owner   => 'root',
      group   => 'root',
      mode    => '0644',
      content => template('facts/app.erb'),
    }
  }
  else {
    file{'/etc/facter/facts.d/app.txt':
      ensure => absent,
    }
  }
}

cat app.erb
app=<%= @app %>