How to have a Puppet module install a particular version of something (docker, for instance)

193 views
Skip to first unread message

David Karr

unread,
Jun 17, 2016, 5:36:00 PM6/17/16
to Puppet Users
I'm stepping through "Puppet for Containerization".  The very first exercise fails to start up the docker service, apparently because of an invalid command-line option ("-d") sent to docker in the systemd service description.  This is being done by the "garethr/docker" Puppet module from the forge. I determined that this was happening because the exercise was specifying a somewhat older version of the module, and simply changing the Puppetfile to use the newer version fixed the problem.  Apparently this option used to be valid in an older version of docker, but had since been removed.

It occurred to me that this situation likely happened because the Puppet module was written a while ago, and it likely just specified to install the latest version of docker.

What I'd like to understand, at least in the scope of this particular module (https://github.com/garethr/garethr-docker), and perhaps in general, what exactly is a "best practice" for specifying an exact version of a dependency to install, as I likely wouldn't have seen this error if the module installed a specific version of Docker that this was known to work with.

I did search through the code of the module, but although seeing that perhaps https://github.com/garethr/garethr-docker/blob/f1f701c5d4845c6dbb85d817d99a4cf9b0c2edae/manifests/params.pp is where this might go, I didn't see a clear answer for how this might have been changed to do that.

Just so it's clear, I'm not suggesting that this change should be made in this particular module, but if I did have a module that had to work with a particular version of one or more dependencies, understanding how this module would be changed to effect that might be a good guide in the future.

Gareth Rushgrove

unread,
Jun 18, 2016, 1:56:16 PM6/18/16
to puppet...@googlegroups.com
The general approach is to set default values in the params.pp.

In fact the module in question does that for Compose here:

https://github.com/garethr/garethr-docker/blob/master/manifests/params.pp#L74

I took the decision to set the default to latest for the version of
docker installed because Docker itself moves quite quickly. And you
nearly always want the latest released version in this case imho.

If instead I'd preferred to set a specific version for the module then
I would have set a default value in params.pp here:

https://github.com/garethr/garethr-docker/blob/master/manifests/params.pp#L6

(mainly because Docker moves quite quickly) they have a habit of
breaking changes in minor versions. I try and call this out in the
Changelog when this happens, for instance for this particular case:
https://github.com/garethr/garethr-docker/blob/master/CHANGELOG.md#2016-02-12---version-51

Gareth

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/dbac3102-c2ec-4d26-8f71-7a51e992eeac%40googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.



--
Gareth Rushgrove
@garethr

devopsweekly.com
morethanseven.net
garethrushgrove.com

David Karr

unread,
Jun 19, 2016, 12:14:37 AM6/19/16
to Puppet Users

Thanks for the reply, Gareth.

As someone who strives for build repeatability, it sounds to me like the reasoning you gave (volatile versioning) would be the reason to NOT always use the latest.

Gareth Rushgrove

unread,
Jun 19, 2016, 3:00:02 AM6/19/16
to puppet...@googlegroups.com
At least as a Docker user I nearly always want to be running latest.
In my experience with fast moving software you're best biting the
bullet and paying the incremental cost of regular upgrades, rather
than say doing jumps from 1.8 to 1.12. In cases where you want to run
a specific version you can be explicit about the version either in
your Puppet code or in hiera. So it's the default rather than a hard
requirement.

To clarify as well, when I said latest I really meant 'present' in
Puppet terms. So you get the latest version on first install, but it's
not set to automatically update existing installs, unless of course
you set your hiera or the relevant parameter to 'latest'.

A lot of this depends on how you use Puppet and how you roll out changes mind.

Most modules take the same approach, ie. specifying the relevant
package should be 'present', which means on first install on a clean
system you get the latest version.

Gareth

> --
> 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...@googlegroups.com.
> To view this discussion on the web visit
> https://groups.google.com/d/msgid/puppet-users/bf4352e2-429c-4835-8421-e72349b94761%40googlegroups.com.
Reply all
Reply to author
Forward
0 new messages