I would nevetheless add the environment in your hierarchy, like 
environment/%{environment}



Then create the 1% settings in eg <hieradata>/environment/production.yaml

end also in your common.yaml (or default.yaml)



All your other environments will use the common ones, production  will have 
there own values.



grts



johan





-----Original message-----
From: Matthew Ceroni <matthewcer...@gmail.com>
Sent: Tuesday 8th March 2016 9:23
To: Puppet Users <puppet-users@googlegroups.com>
Subject: [Puppet Users] Hiera repository + environments + r10k

Question to the community. This isn't really a specific Puppet issue but more a 
question around the workflow that others are using.

My basic setup is a git repository per module. Then I have a, what I call 
control repo, that contains my Puppet file plus all my roles and profiles and 
hiera data. My hiera hierarchy doesn't include environment because each branch 
of the control repo (and module repos) corresponds to an environment (r10k) and 
that is how I obtain different data based on environment. However this is where 
the problem lies. 

For 99% of the hiera data, it should be in sync across environments. However, 
there are cases (as an example as Java memory limit) that should always differ 
between development and production. But with the setup I have if it is hard to 
maintain that separation because a git merge of development up the chain (qa, 
staging, production) is going to take that config setting and merge it. 

I have thought about moving the hiera data out of the control repo to its own 
repository. That way when you are making changes to profiles or roles you can 
safely merge those through the development life cycle.  If I move it to its own 
repository I still have a choice to make. I can create branches and have r10k 
create those as environments on the Puppet server. But this still results in my 
initial issue. You could make a change to the development branch and 99% of the 
data you set you want to merge to qa and so forth but there is that one value 
that is specific to dev and should differ in the other environments. You could 
solve this by a manual process that after the merge the user has to remember to 
set the environment specific value such that it differs. The other option is to 
not have branches corresponding to environments for the hiera data and instead 
insert environment into the hierarchy.

Just wondering what others have done and what approaches they have taken to 
solve this issue? Maybe there is some feature of git I am not aware of where I 
can systematically pick what to merge and what not (although if that was 
possible I can see it being very confusing). 

Thanks

-- 
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 
<mailto:puppet-users+unsubscr...@googlegroups.com> .
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/d5254a2f-1f4d-4eb9-984b-2e30ad13c435%40googlegroups.com.
For more options, visit 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+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/puppet-users/zarafa.56dee810.5245.2dd138825acf1338%40zarafa.open-future.be.
For more options, visit https://groups.google.com/d/optout.

Reply via email to