The number of branches you have has almost nothing to do with how fast your nodes converge to a new desired state. If you want them to check in on command, use mcollective or another orchestration engine to make that happen.
On Thursday, August 18, 2016, Alex Samad <[email protected]> wrote: > Hi > > I have recently gone through this problem. > > I had initial thought to you different branches for the different > environments. > say > prod > uat > sim > inf > dev > > But was advised best to go with production and testing. > > > so I have and I have used a grouping in my ENC to put machines into the > above groups. But I am about ready to go back to more branches again. Why > > I have setup my profiles > > my_ssh profile this handles all the general setup of ssh server and client > - standard across all machines > > > so my roles just include profile::my_ssh > > My issue with this is if I want to now role out a change to my ssh setup I > can't isolate which box gets its, pot luck, wait long enough and they all > get it. > > I am not sure its the best to go to each dev/uat machine and run puppet > --environment <mytest> is the best solution plus my ENC sets the > environment .. don't want pesky dev guys change environments on me. > > I don't want to have to create a new profile and attach it to the roles I > want to test on. > > So I am thinking ... multiple branches is sounding good. > > But im keen to see what comes out of this. > > > On Friday, 19 August 2016 02:24:58 UTC+10, Rob Nelson wrote: >> >> The term 'environment' is overloaded. In the context of puppet, I prefer >> to think of it as "a set of puppet code/data representing a branch of the >> controlrepo' (puppet environment), rather than 'an environment that nodes >> run in' (dev/qa/prod/etc) (node environment). Since you can make the latter >> part of your hiera hierarchy, the only puppet environment that needs to >> live forever is 'production'. Inside it, the hieradata has ALL the data for >> all of the node environments, so they actually all check into 'production'. >> The hierarchy value for the node environment can be a custom fact, >> calculated or a file on disk, so nodes can get the right node environment >> data from the puppet environment 'production'. >> >> :hierarchy: >> - "nodes/%{::trusted.certname}" >> - "node_env/%{node_env}" >> - "common" >> >> By differenting the various uses of the overloaded term 'environment' a >> bit, you can actually streamline your workflow quite a bit. Now all your >> data is in one place. When you create a feature branch for testing, you can >> then point the canary nodes to that branch (`puppet agent -t --environment >> ticket1234`, or putting `environment = ticket1234` in puppet.conf). Whether >> you're changing roles and profiles, hiera data, or the Puppetfile, it's >> contained in that branch, but you can actually have production, dev, qa >> nodes check into it and get the new results, so you aren't surprised when a >> Puppetfile change in dev trickles up to prod and suddenly things blow up. >> Of course, you need to have some canary nodes in each node environment (or >> place a LOT of trust in --noop mode) to get there, but I think that's a >> reasonable goal to work toward. >> >> >> >> Aside: I know we have discussed workflows and the various types of >> environments on this list quite a bit this Spring/Summer. Does anyone have >> a good reference article for this already, or do we need to come up with >> one? I think this is an important gap to fill. >> >> >> Rob Nelson >> [email protected] >> >> On Thu, Aug 18, 2016 at 12:07 PM, Mike Sharpton <[email protected]> >> wrote: >> >>> The static branches are basically Puppet environments in which nodes are >>> bound/pointed to them in their puppet.conf. This way we can open CR's per >>> set of nodes and move up the chain. Also, I may have found another option >>> on Gary's site. We could r10k our hiera data and split it from our control >>> repo. More to come. Thanks again for thoughts. >>> >>> >>> On Thursday, August 18, 2016 at 10:00:01 AM UTC-5, Christopher Wood >>> wrote: >>> >>>> I'm missing why you need static branches. I'm picturing something more >>>> like: >>>> >>>> git checkout production >>>> git checkout -b ticket1234 >>>> # make changes, commit, push, test, repeat >>>> git merge production # catch up on any prod changes, retest >>>> git tag ticket.1234 >>>> git checkout production >>>> git merge ticket1234 >>>> git branch -d ticket1234 >>>> >>>> That way everybody's changes are working pretty close to what >>>> production is right now. >>>> >>>> The alternatives are curating your branches, periodically re-branching >>>> from production, or just accepting the current state, as near as I can tell >>>> off the cuff. If you want to maintain something it requires maintenance >>>> work no matter the tool you pick. >>>> >>>> >>>> On Thu, Aug 18, 2016 at 05:27:40AM -0700, Mike Sharpton wrote: >>>> > Thanks for your reply. We based our initial design on shit Gary >>>> says. >>>> > This may be our only option as you say, to have hiera data >>>> changes made >>>> > to each static branch/puppet environment by hand and not merge. >>>> We need >>>> > the static branches for separation of Puppet environments. >>>> Problem with >>>> > this approach is humans will make errors between each branch >>>> sometimes or >>>> > always. The branches/environments will eventually become snow >>>> flakes over >>>> > time as far as Hieradata. Perhaps we can possibly merge them >>>> weekly to >>>> > lower this risk. Assuming no code changes are in flight, which >>>> there most >>>> > likely always will be. The search continues. Thanks again, >>>> > Mike >>>> > >>>> > On Wednesday, August 17, 2016 at 3:52:31 PM UTC-5, Christopher >>>> Wood wrote: >>>> > >>>> > It sounds like these might help: >>>> > >>>> > [1]https://puppet.com/blog/git-workflows-puppet-and-r10k >>>> > >>>> > [2]http://garylarizza.com/blog/categories/r10k/ >>>> > >>>> > Seems like you would benefit from having all teams work from >>>> branches of >>>> > current production and merge back, rather than maintaining a >>>> > semi-permanent dev branch shared by everybody. This is usually >>>> where I >>>> > suggest that people review commits and talk to each other and >>>> figure out >>>> > what's good, but sometimes that's like pulling teeth. >>>> > >>>> > On Wed, Aug 17, 2016 at 01:21:45PM -0700, 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 [1][3][email protected]. >>>> > > To view this discussion on the web visit >>>> > > >>>> > [2][4]https://groups.google.com/d/msgid/puppet-users/9d9e1 >>>> 8a4-a6e4-4d04-b0b3-377b848a8504%40googlegroups.com. >>>> > > For more options, visit [3][5]https://groups.google.co >>>> m/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 [6][email protected]. >>>> > To view this discussion on the web visit >>>> > [7]https://groups.google.com/d/msgid/puppet-users/cfcde2dc- >>>> 2904-4286-bd01-c934857c0ee5%40googlegroups.com. >>>> > For more options, visit [8]https://groups.google.com/d/optout. >>>> > >>>> > References >>>> > >>>> > Visible links >>>> > 1. https://puppet.com/blog/git-workflows-puppet-and-r10k >>>> > 2. http://garylarizza.com/blog/categories/r10k/ >>>> > 3. javascript: >>>> > 4. https://groups.google.com/d/msgid/puppet-users/9d9e18a4-a6e4 >>>> -4d04-b0b3-377b848a8504%40googlegroups.com >>>> > 5. https://groups.google.com/d/optout >>>> > 6. mailto:[email protected] >>>> > 7. https://groups.google.com/d/msgid/puppet-users/cfcde2dc-2904 >>>> -4286-bd01-c934857c0ee5%40googlegroups.com?utm_medium=email& >>>> utm_source=footer >>>> > 8. 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 [email protected]. >>> To view this discussion on the web visit https://groups.google.com/d/ms >>> gid/puppet-users/b4d986ee-a5e4-4c40-9e0e-2d3d32f35b18%40googlegroups.com >>> <https://groups.google.com/d/msgid/puppet-users/b4d986ee-a5e4-4c40-9e0e-2d3d32f35b18%40googlegroups.com?utm_medium=email&utm_source=footer> >>> . >>> >>> 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 [email protected] > <javascript:_e(%7B%7D,'cvml','puppet-users%[email protected]');> > . > To view this discussion on the web visit https://groups.google.com/d/ > msgid/puppet-users/1527405f-dda2-4a6b-b35a-70cea5618021%40googlegroups.com > <https://groups.google.com/d/msgid/puppet-users/1527405f-dda2-4a6b-b35a-70cea5618021%40googlegroups.com?utm_medium=email&utm_source=footer> > . > For more options, visit https://groups.google.com/d/optout. > -- Rob Nelson [email protected] -- 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/CAC76iT9QTAK%2B_FBC%3D8_QtYm8C_vHWQTq9XkQBccJC9JHSsWc0g%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
