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 <[email protected]>
Sent: Tuesday 8th March 2016 9:23
To: Puppet Users <[email protected]>
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 [email protected]
<mailto:[email protected]> .
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 [email protected].
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.
