Thanks for your reply. We based our initial design on shit Gary says. This may be our only option as you say, to have hiera data changes made to each static branch/puppet environment by hand and not merge. We need the static branches for separation of Puppet environments. Problem with this approach is humans will make errors between each branch sometimes or always. The branches/environments will eventually become snow flakes over time as far as Hieradata. Perhaps we can possibly merge them weekly to lower this risk. Assuming no code changes are in flight, which there most likely always will be. The search continues. Thanks again,
Mike On Wednesday, August 17, 2016 at 3:52:31 PM UTC-5, Christopher Wood wrote: > > It sounds like these might help: > > https://puppet.com/blog/git-workflows-puppet-and-r10k > > http://garylarizza.com/blog/categories/r10k/ > > Seems like you would benefit from having all teams work from branches of > current production and merge back, rather than maintaining a semi-permanent > dev branch shared by everybody. This is usually where I suggest that people > review commits and talk to each other and figure out what's good, but > sometimes that's like pulling teeth. > > > > On Wed, Aug 17, 2016 at 01:21:45PM -0700, Mike Sharpton wrote: > > Hey all, > > We are coming up on an issue in our environment in where we have > multiple > > Puppet environments that are backed by git branches in a puppet > control > > repo. Our Hiera data is stored inside these branches and changed > > frequently by our Operations teams. Of which we then have them merge > > changes up the environment chain and r10k through our Puppet > environments. > > This is all fine. > > Ex, dev -> test -> production, hiera data changes are moved up and > tested > > each step of the way. > > When things aren't fine is when we are testing code in our dev or > test > > branch and we have changed the tags for modules/repos inside the > > Puppetfile of those branches that we don't want in production right > away > > (dev/test). This code only applies to dev environment, on purpose. > > Our operations team then comes along with their hiera changes and > merges > > the puppetfile module/repo changes up the chain along with the hiera > data. > > Effectively moving our Puppetfile changes up the chain when we don't > want > > to. We have thought about splitting hiera data out our puppet > control > > module like it was before Puppet 4, but this leaves us no room to > test > > hiera data up our environment chain and also leaves us with some CI > work > > to make this feasible. Having the hieradata in each environment is > too > > nice. We also attempted to monkey with .gitignore, but this is not > meant > > to do what we are trying to do. Don't merge Puppetfile unless I want > to. > > Has anyone ran into this and found a somewhat elegant solution? > > Everything we are coming up with is either not easy to manage, or > just > > doesn't make sense to do. Perhaps we are missing something simple > and are > > over thinking things. Thanks in advance. > > Mike > > > > -- > > 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 [1]puppet-users...@googlegroups.com <javascript:>. > > To view this discussion on the web visit > > [2] > https://groups.google.com/d/msgid/puppet-users/9d9e18a4-a6e4-4d04-b0b3-377b848a8504%40googlegroups.com. > > > > For more options, visit [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+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/cfcde2dc-2904-4286-bd01-c934857c0ee5%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
