"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."
that should read *isn't* that much of an issue". On Saturday, August 20, 2016 at 9:04:34 PM UTC-4, Chadwick Banning 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. > > 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] >> > On Saturday, August 20, 2016 at 9:04:34 PM UTC-4, Chadwick Banning 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. > > 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 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/0fc5288e-abd7-4c2a-9cb9-6074391df28f%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
