How to use multiple versions of same module

[Eric Berg]

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

[Peter Meier]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

> 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?

At the moment the best thing is: You don't

But you could (ab-)use environments for that, however this introduces
new workflows/changes, but is probably the best idea.

best

pete

-----BEGIN PGP SIGNATURE-----

iEYEARECAAYFAlWZRx0ACgkQbwltcAfKi39osACfYlDQqdUMg6tYXr5UMEKxTnxM
QLoAn1O37j3tVptmdlelvH0uMgz1r1s3
=774L
-----END PGP SIGNATURE-----

[Corey Osman]

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