FAQ
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

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

Search Discussions

  • Luke Bigum at Jan 9, 2013 at 9:11 am
    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

    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
    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To view this discussion on the web visit https://groups.google.com/d/msg/puppet-users/-/4d_axfRmI-QJ.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Brad Ison at Jan 9, 2013 at 6:43 pm

    On Wed, Jan 9, 2013 at 3:11 AM, Luke Bigum 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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Erik Dalén at Jan 11, 2013 at 6:18 pm
    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.
    On Jan 9, 2013 7:43 PM, "Brad Ison" wrote:
    On Wed, Jan 9, 2013 at 3:11 AM, Luke Bigum 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

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

    On Fri, Jan 11, 2013 at 12:10 PM, Erik Dalén 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

    --
    You received this message because you are subscribed to the Google Groups "Puppet Users" group.
    To post to this group, send email to puppet-users@googlegroups.com.
    To unsubscribe from this group, send email to puppet-users+unsubscribe@googlegroups.com.
    For more options, visit this group at http://groups.google.com/group/puppet-users?hl=en.
  • Andreas Dvorak at Nov 3, 2014 at 2:11 pm
    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

    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cb539ce7-daa7-4421-bc26-e772ccdbf3ed%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.
  • Jeremy T. Bouse at Nov 3, 2014 at 4:42 pm
    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
    On 03.11.2014 09:11, Andreas Dvorak wrote:
    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

    --
    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 [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+unsubscribe@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
    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/ba99ab7cdae6133ddc9590896a2ac499%40undergrid.net.
    For more options, visit https://groups.google.com/d/optout.
  • Andreas Dvorak at Nov 4, 2014 at 9:50 am
    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 %>


    --
    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 view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/0a79c776-7d9f-4a51-ad34-5bdb0cf9dfb7%40googlegroups.com.
    For more options, visit https://groups.google.com/d/optout.

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
grouppuppet-users @
categoriespuppet
postedJan 8, '13 at 10:33p
activeNov 4, '14 at 9:50a
posts8
users5
websitepuppetlabs.com

People

Translate

site design / logo © 2022 Grokbase