EDIT: I've found this link by Gary which details how to change the basemodulepath for each environment.conf file to effectively read in a monolithic repo containing all of the desired modules in your puppetfile ( http://garylarizza.com/blog/2014/03/07/puppet-workflow-part-3b/ ). My modified question is once this has been implemented, is there any way to implement a more precise module control in the puppetfile i.e pass references or commit tags if the modules had been in individual repos?
On Wednesday, June 15, 2016 at 3:27:10 PM UTC-4, broncosd183 wrote: > > Hey all, > I'm currently starting to implement the puppetfile format and have hit a > wall of sorts. We currently are stuck on that old monolithic repo of > modules and are eventually looking to move away from this sometime in the > near future. My question is, for now is there any way to make a puppetfile > for individual modules within this repo? We have hosted it on github and I > understand how to pass the url and references if the modules are in their > own repos. Can the same be done for modules in our monolithic repo? At the > very least we were hoping to make a puppetfile for the current repo > configuration and slowly transition out of it and update the puppetfile > accordingly. > > Thanks! > > On Wednesday, June 15, 2016 at 11:35:33 AM UTC-4, Bret Wortman wrote: >> >> I made the conversion a little over a year ago and it's been a dream ever >> since. The Puppetfiles aren't that hard -- We store each module in its own >> repo and use branches to determine environments. For each new environment >> we want to use, we just branch the "puppet" repo which contains the >> Puppetfile and let it know which modules will be under test for this >> environment. It's a lot simpler than it sounds. >> >> On Wednesday, June 15, 2016 at 11:27:28 AM UTC-4, broncosd183 wrote: >>> >>> Awesome thanks for the feedback and options Rich and Christopher. I'm >>> outlining a plan of attack now and going to make a pass at installing R10k >>> and configuring it correctly. The main hurdle was the puppetfile and its >>> dependencies; however, that looks much more feasible now. >>> >>> On Friday, June 10, 2016 at 10:56:03 AM UTC-4, Rich Burroughs wrote: >>>> >>>> I'm assuming this could be done. We're talking about UNIX she'll >>>> commands and there's a way to do just about anything. But I can't imagine >>>> it being simple or fun to use. Like could you do Pull Requests on Github >>>> between these repos? Maybe, depending on how you set it up. People >>>> nowadays >>>> recommend against monolithic repos too, and that's what you'd have. You'd >>>> just have a bunch of them. >>>> >>>> The normal recommended workflow with r10k is using branches for those >>>> environments, not separate repos. Then you have the ability to merge >>>> between branches, so it's easy to promote those changes along your >>>> pipeline. >>>> >>>> I remember back before I started using r10k, it seemed very confusing >>>> to me. I think there's a bit more info out about it now. In terms of >>>> getting a Puppetfile setup, one of the hard things there is that you need >>>> to account for all of the dependencies. Rob Nelson made this cool Ruby gem >>>> that makes generating the file a bit easier. You can pass it a set of >>>> Forge >>>> modules and it will also include their dependencies: >>>> >>>> >>>> https://github.com/rnelson0/puppet-generate-puppetfile/blob/master/README.md >>>> >>>> It's pretty slick. >>>> >>>> Personally I'd recommend you stick it out and figure out how to make >>>> r10k work for what you're doing. I would bet you'd be glad you did after. >>>> If you have problems ask specific question here or IRC or Slack. There are >>>> a lot of people using it now and there should be lots who can help. >>>> >>>> >>>> Rich >>>> On Fri, Jun 10, 2016 at 7:34 AM Funsaized <[email protected]> wrote: >>>> >>>>> Hello, >>>>> >>>>> I am relatively new to puppet and am trying to develop a good workflow >>>>> in conjunction with git/github to keep a better version control system. >>>>> The >>>>> version of puppet that I am working with and has been implemented is a >>>>> bit >>>>> dated, and using R10k and developing a puppetfile would be quite time >>>>> consuming. I know that R10k and dynamic environments is the recommended >>>>> way >>>>> of doing things, though for now I'm not sure if its the best for my >>>>> scenario and how everything has been previously set up. My question is is >>>>> there a simple way to just map one git repo for each environment (dev, >>>>> QA, >>>>> production, etc). That way changes could be made in the dev environment, >>>>> then moved over to the correct repos when the changes are confirmed in >>>>> order? Would this be as simple as declaring each folder withing the >>>>> /puppet/environments folder as a git repo and controlling that way? >>>>> >>>>> Deployment strategy >>>>> >>>>> - Upload changes to Dev repo >>>>> >>>>> - Deploy Dev changes to Dev master >>>>> >>>>> - Test >>>>> >>>>> - Merge Dev changes to QA repo >>>>> >>>>> - Rinse and repeat >>>>> >>>>> -- >>>>> 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/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%40googlegroups.com >>>>> >>>>> <https://groups.google.com/d/msgid/puppet-users/fe80ff27-af02-4437-bbc9-57c1cd56e5aa%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]. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/4860f7e0-84f7-4627-b33e-722812c340c7%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
