On 19 June 2016 at 01:14, David Karr <davidmichaelk...@gmail.com> wrote:
> On Saturday, June 18, 2016 at 6:56:16 AM UTC-7, garethr wrote:
>>
>> On 17 June 2016 at 18:36, David Karr <davidmic...@gmail.com> wrote:
>> > 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.
>> >
>>
>> 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.
>
>
> 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.
>
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+unsubscr...@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.
>
> For more options, visit https://groups.google.com/d/optout.
--
Gareth Rushgrove
@garethr
devopsweekly.com
morethanseven.net
garethrushgrove.com
--
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/CAFi_6y%2BLvStbnmyRqkV%2Bqi6wF7mO0UkSDNWPEhzBxxk6DmUavA%40mail.gmail.com.
For more options, visit https://groups.google.com/d/optout.
