This is an issue I run into pretty regularly. If your Puppet infrastructure is even moderately complex, I'd recommend NOT equating a Puppet environment to an operational environment, operational environment being the groups of machines known as dev, qa, staging, etc.
For instance, in my infrastructure we have 50+ different operational environments. If I equate each one of these to a Puppet environment, I'd need 50+ branches. While doable, this immediately becomes a nightmare if I have a change that applies to all or some of the operational environments -- say, changing something in my base profile. Now I have to a) hope all 50+ branches are somewhat in sync, and b) merge my change into *each* branch 50+ times. If the branches aren't in sync at all I very well might end up having to fix unique conflicts each time I merge. This is *not* a place where you want to end up. On Wednesday, August 17, 2016 at 4:21:45 PM UTC-4, 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 [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/8abde89d-dfec-486e-b0ba-7ced6b6e07d8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
