It depends on what you mean by slowly rolling out the change. Do you control the openssh version globally (all machines get same version)? Or is the version set per *operational* environment (dev machines have newer version than prod machines, etc)?
If you set the version globally, and you want to control the rollout in some way, you'd do this via Puppet environments. If you control the version in individual operational environments, and you have facts that distinguish these, you'd use these facts with Hiera changes to control the rollout across different operational environments. Again, this complexity only comes into play when you need to be able to stage rollouts across Puppet environments AND operational environments *independently*. This is just *one* way to possibly handle this complexity. I certainly always have my eyes and ears open for better/simpler solutions. On Sun, Aug 21, 2016 at 11:20 PM, Alex Samad <a...@samad.com.au> wrote: > 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 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/CAJ%2BQ1PWS3LHBWE6Z-h8Newbo_R7qdh4qn-yADxqWMbJLv8Ga4Q% > 40mail.gmail.com. > For more options, visit https://groups.google.com/d/optout. > -- Chadwick Banning -- 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/CAPwwW9H%3DZYz_WZVQ375Dugm8jg7Q8jtrNFP-D12TBgRh0aX-2Q%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
