Have you looked at including these modules inside your r10k controlrepo? >From a workflow perspective, that might be easier (branch, tweak files, PR/merge to `production`), though there may be issues surrounding access and permissions, of course. Have a gander at http://garylarizza.com/blog/2015/11/16/workflows-evolved-even-besterer-practices/ for controlrepo theory and http://rnelson0.com/2015/04/15/improved-r10k-deployment-patterns/ which details the conversion from modules in other repos to a consolidated controlrepo.
If access rights are an issue, you could have a standalone module that is pushed out by r10k via cron on a regular basis, across all repositories. See https://github.com/puppetinabox/controlrepo/blob/production/Puppetfile#L51-L53 and https://github.com/puppetinabox/controlrepo/blob/production/dist/profile/manifests/puppet_master.pp#L25-L29 as an example of this. This would push the current version of that module to every environment that exists at the time. I believe that if you specify a certain ref/branch inside an environment, it will deploy that ref/branch, otherwise it deploys the default branch of the repo, but would certainly verify that if you go down that road. Rob Nelson rnels...@gmail.com On Tue, Sep 27, 2016 at 6:09 PM, Robert Davidson < robert.david...@nominum.com> wrote: > We're still running puppet 3.6.2, and are finally getting around to trying > to implement R10K. For assorted reasons, we have not been able to do this > before now, and have a very large stack of home-grown modules that are all > sitting in a monolithic repo. For the most part, it's been straightforward. > We are splitting up the modules into their own repos, tagging them with > version numbers, etc. But I've now hit an issue that's got me blocked. > > We have several modules that include important data files inside them. > (Which is bad practice, I know, but many of these were written a while ago > and we're slowly working to refactor.) > In our current, monolithic setup, they reside in paths like this: > git/puppet/environments/production_ng/modules/$MODULE/ > files/customers/$FILENAME > > Each $FILENAME must be pushed out, with that name and it's contents, to a > particular directory on the machine using the module. The files contain > anywhere from ten to a hundred lines of config, varying per customer. At > the moment, we push them using a recursive file resource into the directory. > > Under r10k, we want to use tags to mark version numbers and pull them into > environments. But these config files need to change rapidly, and would > result in ridiculous version creep if we increment every time we had to > adjust one of them. What is a good way to deal with data files like this > (ones where putting the contents into hiera is not really viable)? How do I > treat them under R10K? > > -- > Robert Davidson > > -- > 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/1EE73329D6577F44A3C2FB0F7D4ACAE98D244374%40mbx-02. > 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/CAC76iT-urwaEHe8KiJf81Y5jcdPF7%3Dg%3D%2B-HDhy0VUSG-2bTmJQ%40mail.gmail.com. For more options, visit https://groups.google.com/d/optout.
