"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 <[email protected]> >> 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 <[email protected]> >> 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 [email protected]. 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.
