So the end goal would be to use r10k. However, in the midterm you need to do a few things.
1. Create a roles and profiles pattern for your business logic 2. version your modules inside your VCS. So basically you can create a nginx_profile1_2, nginx_profile_1_3, ... as well as a nginx_1_1 and nginx_1_2 that way you can mix and match module versions with profile versions and then slowly remove the legacy code once all your nodes have been migrated off the legacy code. You would still have a mono repo but at least you don't have to worry about backwards compatibility because each module is versioned inside your VCS. Obviously this will create a lot more modules but it gives you some flexibility. Now you could put all these "versioned modules" inside R10K as well to give you even more flexibility but I think you would want to stick with one environment as having all these versioned modules will introduce unwanted complexity when you have multiple environments. This used to be a good pattern before r10k and librarian-puppet came onto the market. Corey On Saturday, July 4, 2015 at 5:10:44 PM UTC-7, Eric Berg wrote: > > Seems like a problem that people run into all the time, but I haven't > found any info on this topic that is in the least satisfying. > > I have a monolithic puppet repo that is several years old, and which has > one main "module" with several dozen manifests along with files and > templates. Currently, this code uses 3rd party/forge modules that are > pretty old, and I'd like to update the 3rd party modules (stuff like apt, > nginx, node, stdlib, etc...), but I need to do it selectively, since many > of our manifests may break in a major-version upgrade. > > As I create proper modules from the manifests that we have now, the > existing "module" should continue to use the versions they're currently > using and the new ones should be able to use the latest versions of these > modules. > > Simply installing modules, for example by using 'puppet module install' > updates the current version of the module, which resides in our git repo in > the modules subdir. > > Ultimately, it seems that we should move to librarian puppet, but I'm not > sure that that solves the basic problem, which is that I need to have > multiple versions of the same modules. > > How do I accomplish this? > > Thanks. > > Eric > -- 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/8f6e5eb4-89d7-4163-8b66-a931c96855b8%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
