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 [email protected] On Tue, Sep 27, 2016 at 6:09 PM, Robert Davidson < [email protected]> 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 [email protected]. > 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 [email protected]. 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.
