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 <sai...@gmail.com> 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 puppet-users...@googlegroups.com. >>>> 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 puppet-users+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/puppet-users/9e2a48a4-078e-40d0-9f24-73cab6d20279%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
