On 21 August 2016 at 11:04, Chadwick Banning <chadwickbann...@gmail.com> wrote: > As Rob Nelson mentioned above, you can differentiate between operational > environments in Hiera as long as you have the appropriate facts available. > > If you differentiate Puppet environments and operational environments, then > it's easier to address staged rollouts in each appropriate context. Staged > rollouts of changes across *operational* environments may be done through > Hiera, and staged rollouts of Puppet code (usually common Puppet code that > cuts across operational environments) can be done through *Puppet* > environments. > > If your environment is simple enough...such as a single app with dev, > staging, and production operational environments, then equating a Puppet > environment to an operational environment is that much of an issue. For more > complex Puppet setups, equating them always creates issues IMHO.
Okay I get it you have another branch in hiera lets say env as you have above. But they pull in the same profile class - lets say openssh. So lets say ssh come out with v3, you want to slowly roll out. Do you have a bit if then or case switch statement in your ssh profile class or do you create a new ssh class call ssh-v3 and then assign it to only the env you want to. seems like every time you want to make a change to a profile/class you need to create another one so you can control the roll out or you have a big if/then or switch case to do that for you. trying to persist with the 2 branches production and testing for now .. > > This topic is really interesting to me since I've run into it multiple > times, the last being very recent. > > On Saturday, August 20, 2016 at 6:39:03 PM UTC-4, Alex Samad wrote: >> >> On 20 August 2016 at 22:50, Chadwick Banning <chadwic...@gmail.com> wrote: >> > 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. >> >> But how to you stage a roll out of an update. If you want it to go to >> dev then uat then prod ... or through some logical steps. >> >> presuming you have a common profile used by all. >> >> > >> > 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. >> >> Yes agree sounds like it would be a nightmare >> >> > >> [snip] > > -- > You received this message because you are subscribed to a topic in the > Google Groups "Puppet Users" group. > To unsubscribe from this topic, visit > https://groups.google.com/d/topic/puppet-users/4YL6D4wwJww/unsubscribe. > To unsubscribe from this group and all its topics, 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/272fba59-9684-44b1-8350-417893cbfb9e%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/CAJ%2BQ1PWS3LHBWE6Z-h8Newbo_R7qdh4qn-yADxqWMbJLv8Ga4Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
