Hi Robert! Is separating the customer data an option? That would let you manage the modules without having to increment them constantly, while pulling the customer data from another location - perhaps from a GIT repository using Puppet's vcsrepo module.
- Rilindo -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Robert Davidson Sent: Wednesday, September 28, 2016 7:23 PM To: '[email protected]' <[email protected]> Subject: RE: [Puppet Users] R10K in an existing infrastructure OR How to write yourself into a corner. I would prefer not to have to treat these modules any differently than the rest - the only thing about the problem modules is that they include data files that need to be pushed intact. Putting them into the control repo would diverge them from the way we want to handle all other modules, which strikes me as sub-optimal. I'm mostly looking to see if anyone else has experience handling situations like this, and if they were able to come up with a way to handle it without changing how modules are handled. One thing we did think about was to create a "data" module that contains files like these, and are referred to inside r10K by branch rather than tag, letting us continue to treat the bulk of the module correctly while isolating our config files off to their own space. It's ugly, but could theoretically work. I can't help but feel that there must be a better way to do this, though. -- Robert Davidson > -----Original Message----- > From: [email protected] [mailto:puppet- > [email protected]] On Behalf Of Rob Nelson > Sent: Tuesday, September 27, 2016 4:52 PM > To: [email protected] > Subject: Re: [Puppet Users] R10K in an existing infrastructure OR How to > write yourself into a corner. > > 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/profil > e/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] > <mailto:puppet-users%[email protected]> . > To view this discussion on the web visit > https://groups.google.com/d/msgid/puppet- > users/1EE73329D6577F44A3C2FB0F7D4ACAE98D244374%40mbx-02 > <https://groups.google.com/d/msgid/puppet- > users/1EE73329D6577F44A3C2FB0F7D4ACAE98D244374%40mbx-02> . > For more options, visit https://groups.google.com/d/optout > <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 <https://groups.google.com/d/msgid/puppet- > users/CAC76iT-urwaEHe8KiJf81Y5jcdPF7%3Dg%3D%2B-HDhy0VUSG- > 2bTmJQ%40mail.gmail.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/1EE73329D6577F44A3C2FB0F7D4ACAE98D2478EF%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/01f701d21a03%24bb6afa20%243240ee60%24%40gmail.com. For more options, visit https://groups.google.com/d/optout.
