Docker 20.10 doesn't let the module work.

[pier4r]

Describe the Bug

With docker 20.10 the module (3.11.0) fails. In particular this step fails: /~https://github.com/puppetlabs/puppetlabs-docker/blob/v3.12.1/lib/puppet/provider/docker_network/ruby.rb#L41-L46

Expected Behavior

That it works like with docker 19.03

Steps to Reproduce

1. Get a centos 7.x with docker 20.10
2. have a puppet node with the docker class installed
3. let puppet run
4. This will happen

Debug: Executing: '/usr/bin/systemctl is-active docker'
Debug: Executing: '/usr/bin/systemctl is-enabled docker'
Debug: Prefetching ruby resources for docker_network
Debug: Executing: '/usr/bin/docker network ls'
Debug: Executing: '/usr/bin/docker network inspect ID'
Debug: Storing state
Debug: Stored state in 0.13 seconds
Error: Failed to apply catalog: Execution of '/usr/bin/docker network inspect ID' returned 1: WARNING: Error loading config file: .dockercfg: $HOME is not defined
[]
Error: No such network: ID

Environment

• Version 3.11.0
• Platform Centos 7.x

Additional Context

Docker 20.10 was installed on some of our machines yesterday 2020-12-09 and we noticed the problem popping out.

[sdinten]

sdinten@vps04:~$ unset HOME
sdinten@vps04:/home/sdinten$ docker network ls
WARNING: Error loading config file: .dockercfg: $HOME is not defined
NETWORK ID     NAME         DRIVER    SCOPE
ec49c0686e0c   backend      bridge    local
243b554f6093   bridge       bridge    local
7a5e8f03f4eb   frontend     bridge    local
b0997cf395b1   host         host      local
2e00d2d86671   none         null      local

Puppet does not set $HOME;

line 41 in puppetlabs-docker/lib/puppet/provider/docker_network/ruby.rb:
lines.shift # remove header row

[pelletier2017]

Also seeing this same error on Centos7 with Docker version 19.03.13, build 4484c46d9d

[deubert-it]

Same problem on Debian 10 with Docker version 20.10.0, build 7287ab3

[sebastianTC]

Same problem for docker volumes provider.
Comparing the output of Docker 19 and Docker 20 for docker volume ls I see a small change in formatting. The rows do have less space between them now.

V19:

NETWORK ID          NAME                DRIVER              SCOPE
221c5b5b1a8e        bridge              bridge              local
2cc9f3723cd2        host                host                local
a736b1713b1e        none                null                local
ca646b5c7a1d        source_default      bridge              local

V20:

NETWORK ID     NAME      DRIVER    SCOPE
89b3e1bf93ec   bridge    bridge    local
8dc7fcb06fe6   host      host      local
1c48efcdda68   none      null      local

[deubert-it]

@sebastianTC great you posted the difference between output here, and from what I can see in puppetlabs-docker/lib/puppet/provider/docker_network/ruby.rb line 52 the amount of used spaces is not a problem.

The problem is related to the warning line being parsed as well, which can be seen in the output provided from @sdinten .
WARNING: Error loading config file: .dockercfg: $HOME is not defined

So the actual header row is currently parsed as network entry, and the second value in that row is "ID", which explains the current behaviour.

Best solution:
Set HOME correctly. I don't know the module structure yet, not sure how to properly fix this.

Workaround:
Make the self.instances more defensive in a way that it will remove additional Warnings at the beginning of the output. This can be seen as just masking other problems, so I'm not sure if this is a good idea. Also providing a pattern to check when we actually have the correct header line might be adding more maintenance work, as we would have to react to changes coming from docker related to wording. However, this argument is probably defeated by the current design which already requires intervention if docker changes the output format.

[sebastianTC]

Maybe it would be better/easier to use -q option on docker ls commands which is only giving back the names as a list without any header.
As I see only the name/ID is used and the other parameters are parsed from docker inspect afterwards.

This doenst help in this specific problem but would avoid issues with future changing formatting.

[deubert-it]

@sebastianTC

docker network ls -q
357dbeb47957
3e7fbdd8cfaf
5771ae359391

The module currently makes use of the network name and driver, both would be missing from this view. Not sure if there are additional parameters?

I implemented a local workaround to ignore the Warning in the output for the docker network ls, which seems to work, but then there is just another similar error related to missing $HOME:

Error: Failed to apply catalog: 765: unexpected token at 'WARNING: Error loading config file: .dockercfg: $HOME is not defined
[
    {
        "Name": "bridge",
[..]

So I don't think the workaround is viable.

To fix the missing HOME:
What I don't understand fully yet is where this docker(['network', 'ls']) actually ends up. I can't find a ruby function, but also can't find any reference to an external library. I'm clearly missing something here.

[sebastianTC]

@deubert-it

[sebastian@sebastian-hp sebastian]$ docker network ls -q
221c5b5b1a8e
2cc9f3723cd2
a736b1713b1e
ca646b5c7a1d
[sebastian@sebastian-hp sebastian]$ docker network inspect 221c5b5b1a8e
[
    {
        "Name": "bridge",
        "Id": "221c5b5b1a8e581dc08e4167f94a58426d6ea4438851e107fc690e2a9c4e3deb",
        "Created": "2020-12-11T08:02:06.092601375+01:00",
        "Scope": "local",
        "Driver": "bridge",
        "EnableIPv6": false,
        "IPAM": {
            "Driver": "default",
            "Options": null,
            "Config": [
                {
                    "Subnet": "192.168.0.0/20",
                    "Gateway": "192.168.0.1"
                }
            ]
        },
        "Internal": false,
        "Attachable": false,
        "Ingress": false,
        "ConfigFrom": {
            "Network": ""
        },
        "ConfigOnly": false,
        "Containers": {},
        "Options": {
            "com.docker.network.bridge.default_bridge": "true",
            "com.docker.network.bridge.enable_icc": "true",
            "com.docker.network.bridge.enable_ip_masquerade": "true",
            "com.docker.network.bridge.host_binding_ipv4": "0.0.0.0",
            "com.docker.network.bridge.name": "docker0",
            "com.docker.network.driver.mtu": "1500"
        },
        "Labels": {}
    }
]

The script could get the IDs from the first command directly without removing the header and spliting the lines.
with -q Paramter lines variable is directly holding the IDs which can be used inside the map

_, name, driver = line.split(' ') could be removed and inspect = docker(['network', 'inspect', name]) could be changed to inspect = docker(['network', 'inspect', line])

I think docker command is defined in line 9: commands docker: 'docker'
I'm not into ruby but i think this is a shell command executer which is called with parameters afterwards.

I cannot test it now but docker(['network', 'ls','2>/dev/null']) could work as a workaround.
Atleast docker network ls 2>/dev/null is supressing the warning

docker network ls
WARNING: Error loading config file: .dockercfg: $HOME is not defined
NETWORK ID     NAME      DRIVER    SCOPE
89b3e1bf93ec   bridge    bridge    local
8dc7fcb06fe6   host      host      local
1c48efcdda68   none      null      local 

docker network ls 2>/dev/null
NETWORK ID     NAME      DRIVER    SCOPE
89b3e1bf93ec   bridge    bridge    local
8dc7fcb06fe6   host      host      local
1c48efcdda68   none      null      local 

[cjbnc]

It appears that the Network ID is always a hexadecimal string. Instead of blindly dropping the first line from the output, it might be better to loop through all of the output and use a regex match to skip any lines that don't have a hexadecimal string in the first column.

I'm not sure of the correct ruby code but something like

    output = docker(['network', 'ls'])
    lines = output.split("\n")
    lines.map do |line|
      netid, name, driver = line.split(' ')
      next unless /^[0-9a-f]+$/.match(netid)
      inspect = docker(['network', 'inspect', name])
      # ...

[deubert-it]

My workaround looked like this, and worked fine, but there are more similar calls to docker where the given warning appears and would have to be fixed in multiple locations:

    # now remove all lines at the beginning including the actual header row
    header_found = false
    until header_found do
      header_found = lines.first.match(/NETWORK ID(\s+)NAME(\s+)DRIVER/)
      lines.shift
    end

This workaround will allow the fact collection to finish, but it will error in the configuration application stage in similar form:

Info: Applying configuration version '1607679521'
Error: Failed to apply catalog: 765: unexpected token at 'WARNING: Error loading config file: .dockercfg: $HOME is not defined
[
    {
        "Name": "bridge",

I still think we should focus on actually fixing the missing HOME in the docker cli call, but I am also not a ruby expert.

[gerbdla]

Does anyone have an update on this bug. I updated to version 20.10 got the error then tried several versions of puppetlabs docker and lower versions of Docker and still getting the error. Any ideas?

[sdinten]

@gerbdla I have had a quick look at the suggestion made by @cjbnc (good suggestion btw.) but haven't got time to look into this further for now. Hope to spend some time on it this Sunday

I ran into the same issue after downgrading docker-ce and found that I had to downgrade docker-ce-cli as well, currently running 5:19.03.123-0debian-buster of both docker-ce and docker-ce-cli

[pier4r]

⚠️ we discovered that due to some yum dependencies the solution works but somewhen yum can decide to delete docker altogether. Do not use the following as it is. It has to be made a bit more failsafe.

we used this tempfix for the moment. It works on CentOS. It is not great but better than having puppet blocked.

class global_values::tempfix::ticketnohere {
    if $facts['docker']['ServerVersion'] > '19.03.14' { #to remove when ticketnohere works
        #ticketnohere
        exec { 'remove newer packages':
            #with exec as the package resource is less flexible/known/conflictual(when other classes use it)
            #due to the construction of the if, this should happen only once
            command => 'yum -y erase docker-ce docker-ce-cli',
            path    => [
                '/usr/local/sbin',
                '/usr/local/bin',
                '/usr/sbin',
                '/usr/bin',
            ],
        }
        -> exec { 'install older packages':
            #with exec as the package resource is less flexible/known/conflictual(when other classes use it)
            #due to the construction of the if, this should happen only once
            command => 'yum -y install docker-ce-19.03.14-3.el7 docker-ce-cli-19.03.14-3.el7',
            path    => [
                '/usr/local/sbin',
                '/usr/local/bin',
                '/usr/sbin',
                '/usr/bin',
            ],
        }
        -> Class['profiles::docker']
    }
    else {
        file_line { 'avoid that docker gets updated':
            ensure => 'present',
            path   => '/etc/yum.conf',
            line   => 'exclude=docker*',
        }
        -> Class['profiles::docker']
    }
}

[sdinten]

Created a pull request: #692

Also moved to 20.10 on my debian 10 box and added the main branch of /~https://github.com/sdinten/puppetlabs-docker to my Puppetfile. Puppet runs now run without issues with Docker-ce 20.10 on Debian 10 (including creating new networks if required)

[sdinten]

@sebastianTC I agree, I did not think about this (obviously :)). My PR has already been merged so I cannot update it. Can you make a new PR for this? (maybe we should raise a new issue for this as well?)

[kasimon]

Hmm, the puppet agent is (usually) run as root, so the sensible setting for HOME would be /root, or am I wrong? Would it be possible to detect the home directory of the executing user?

Also, docker doesn't complain if the HOME directory does not exist, so setting HOME to a not existing path would solve the problem as well:

# HOME=/nonexisting docker volume ls
DRIVER    VOLUME NAME
local     <redacted>

I also played around with changing the docker log level up to error or fatal (docker --log-level=error volume ls), but the message is shown anyway (it is probably generated before the command line is parsed).

[pelletier2017]

@deubert-it

I think you could also get the name and driver with the --format command. It solves the parsing other than the WARNING problem.

docker network ls --format '{{.Name}} {{.Driver}}'

[pelletier2017]

Looks like it's fixed in the 3.13.0 release. Thanks!

[cedws]

Has there been a regression or was this not fixed for Docker::Run? The warning I'm getting is the exact same, about $HOME being unset. This code then decides to do something different because stderr is not empty, and in my case, doesn't start the container:

puppetlabs-docker/lib/puppet/functions/docker_params_changed.rb

Line 81 in 4a4e29a

if stderr.to_s == '' && status.to_s.include?('exit 0')

[sdinten]

A quick scan in the docker::run class shows that "it should" set the HOME variable to '/root' when not running on windows. Can you elaborate on the error message and post the versions you use?

puppetlabs-docker/manifests/run.pp

Line 367 in 4a4e29a

$exec_environment = 'HOME=/root'

[cedws]

This is on Ubuntu 20.04 and we're using v4.0.0 of the module. The snippet you posted only covers the Exec resources. The Deferred function doesn't run docker with this in the environment.

puppetlabs-docker/lib/puppet/functions/docker_params_changed.rb

Line 80 in 998d11d

stdout, stderr, status = Open3.capture3("docker inspect #{opts['sanitised_title']}")

[sdinten]

@cedws I tried to reproduce the issue but no luck so far. Can you share your configuration maybe?

Steps taken:

1. Install ubuntu server from 20.04 ISO
2. Install puppet6 agent for focal from puppetlabs repo (apt.puppetlabs.com)
3. Install puppetlabs-docker module puppet module install -v 4.0.0 puppetlabs-docker
4. Apply test.pp puppet apply -t test.pp
5. Check status systemctl status docker-helloworld

root@ubutst:~/puppet# puppet apply -t test.pp
Info: Loading facts
Info: Loading facts
Info: Loading facts
Notice: Compiled catalog for ubutst.home.vandinten.nl in environment production in 0.53 seconds
Info: Applying configuration version '1627131951'
Notice: /Stage[main]/Main/Docker::Run[helloworld]/File[/usr/local/bin/docker-run-helloworld-start.sh]/ensure: defined content as '{md5}fd129e662c77c531bec461c6a2d9929b'
Info: /Stage[main]/Main/Docker::Run[helloworld]/File[/usr/local/bin/docker-run-helloworld-start.sh]: Scheduling refresh of Service[docker-helloworld]
Info: /Stage[main]/Main/Docker::Run[helloworld]/File[/usr/local/bin/docker-run-helloworld-start.sh]: Scheduling refresh of Exec[docker-helloworld-systemd-reload]
Notice: /Stage[main]/Main/Docker::Run[helloworld]/File[/usr/local/bin/docker-run-helloworld-stop.sh]/ensure: defined content as '{md5}f05123a0959f5306dbf623b6bacab257'
Info: /Stage[main]/Main/Docker::Run[helloworld]/File[/usr/local/bin/docker-run-helloworld-stop.sh]: Scheduling refresh of Service[docker-helloworld]
Info: /Stage[main]/Main/Docker::Run[helloworld]/File[/usr/local/bin/docker-run-helloworld-stop.sh]: Scheduling refresh of Exec[docker-helloworld-systemd-reload]
Notice: /Stage[main]/Main/Docker::Run[helloworld]/File[/etc/systemd/system/docker-helloworld.service]/ensure: defined content as '{md5}88d8787d64347930a174baaf27f5d10e'
Info: /Stage[main]/Main/Docker::Run[helloworld]/File[/etc/systemd/system/docker-helloworld.service]: Scheduling refresh of Service[docker-helloworld]
Info: /Stage[main]/Main/Docker::Run[helloworld]/File[/etc/systemd/system/docker-helloworld.service]: Scheduling refresh of Exec[docker-helloworld-systemd-reload]
Notice: /Stage[main]/Main/Docker::Run[helloworld]/Exec[docker-helloworld-systemd-reload]: Triggered 'refresh' from 3 events
Notice: /Stage[main]/Main/Docker::Run[helloworld]/Service[docker-helloworld]/ensure: ensure changed 'stopped' to 'running'
Info: /Stage[main]/Main/Docker::Run[helloworld]/Service[docker-helloworld]: Unscheduling refresh on Service[docker-helloworld]
Notice: Applied catalog in 1.72 seconds

root@ubutst:~/puppet# dpkg -l | grep docker
ii  docker-ce                            5:20.10.7~3-0~ubuntu-focal        amd64        Docker: the open-source application container engine
ii  docker-ce-cli                        5:20.10.7~3-0~ubuntu-focal        amd64        Docker CLI: the open-source application container engine
ii  docker-ce-rootless-extras            5:20.10.7~3-0~ubuntu-focal        amd64        Rootless support for Docker.
ii  docker-scan-plugin                   0.8.0~ubuntu-focal                amd64        Docker scan cli plugin.

root@ubutst:~/puppet# puppet module list --tree
/etc/puppetlabs/code/environments/production/modules
└─┬ puppetlabs-docker (v4.0.0)
  ├── puppetlabs-stdlib (v7.1.0)
  ├── puppetlabs-apt (v8.0.2)
  ├── puppetlabs-translate (v2.2.0)
  ├─┬ puppetlabs-powershell (v5.0.0)
  │ └── puppetlabs-pwshlib (v0.10.0)
  └── puppetlabs-reboot (v4.0.2)
/etc/puppetlabs/code/modules (no modules installed)
/opt/puppetlabs/puppet/modules (no modules installed)

root@ubutst:~/puppet# cat test.pp
include 'docker'

docker::run { 'helloworld':
#  ensure  => absent,
  image   => 'ubuntu:precise',
  command => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
}

root@ubutst:~/puppet# systemctl status docker-helloworld
● docker-helloworld.service - Daemon for helloworld
     Loaded: loaded (/etc/systemd/system/docker-helloworld.service; enabled; vendor preset: enabled)
     Active: active (running) since Sat 2021-07-24 13:05:52 UTC; 2s ago
   Main PID: 16217 (bash)
      Tasks: 9 (limit: 2278)
     Memory: 26.0M
     CGroup: /system.slice/docker-helloworld.service
             ├─16217 bash /usr/local/bin/docker-run-helloworld-start.sh
             └─16276 /usr/bin/docker start -a helloworld

Jul 24 13:05:52 ubutst systemd[1]: Started Daemon for helloworld.
Jul 24 13:05:52 ubutst docker-helloworld[16247]: 8216b8a575c395211128665864b502624f017c7cbc0c2d4b88343c8a8e53820f
Jul 24 13:05:53 ubutst docker-helloworld[16276]: hello world
Jul 24 13:05:54 ubutst docker-helloworld[16276]: hello world
Jul 24 13:05:55 ubutst docker-helloworld[16276]: hello world

[cedws]

@sdinten Cheers for looking into this. Could it be because the shell you're running puppet apply in has $HOME in the environment? In my case Puppet is running as root as a systemd service so $HOME won't be in the environment.

$ dpkg -l | grep docker
ii  docker.io                              20.10.2-0ubuntu1~18.04.2                        amd64        Linux container runtime

$ puppet module list --tree
...
├─┬ puppetlabs-docker (v4.0.0)
│ ├── UNMET DEPENDENCY puppetlabs-translate (>= 0.0.1 < 3.0.0)
│ ├── UNMET DEPENDENCY puppetlabs-powershell (>= 2.1.4 < 6.0.0)
│ ├── puppetlabs-stdlib (v5.1.0) [/etc/puppetlabs/code/environments/production/modules]
│ ├── puppetlabs-apt (v8.0.2) [/etc/puppetlabs/code/environments/production/modules]
│ └── puppetlabs-reboot (v2.1.2) [/etc/puppetlabs/code/environments/production/modules]
...

[sdinten]

'unset HOME; puppet apply -t test.pp` gives the same result on my end. The docker::run class creates a systemd service, stop and start scripts and starts the container as expected.

A thing I noticed is that you use docker.io for ubuntu 18.04, in order to be able to use that I had to change my puppet code to stop managing the package (still my sample code works when using the docker.io package instead of the docker-ce package)

class { 'docker':
  manage_package              => false,
}

docker::run { 'helloworld':
#  ensure  => absent,
  image   => 'ubuntu:precise',
  command => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
}

Can you create a debug log file of the failing puppet run (e.g. puppet agent -t --debug | tee /tmp/puppet.debug) and provide the puppet code that you try to apply
?

Also, if the systemd service is actually created, can you share the output of `systemctl status docker-'?

[cedws]

Sorry, sharing logs is tough because I need to censor things from our production environment. But I think I can give you some steps to reproduce the stderr output from Docker. What happens if you do this:

1. Set up a Ubuntu 20.04 environment (Vagrant works)
2. apt install docker.io
3. Become root
4. unset HOME
5. docker inspect test >/dev/null

What I would expect you to see is this, with the first line being the problem.

WARNING: Error loading config file: .dockercfg: $HOME is not defined
Error: no such object: test

[sdinten]

I am able to reproduce the WARNING: Error loading config file: .dockercfg: $HOME is not defined error but still my puppet code (using docker::run) works (even with the docker.io package). For me to continue to look into this I need the puppet code and the puppet debug output or some kind of reproduction scenario

[cedws]

Right, I've done a bit more investigation starting from scratch. Try this resource declaration:

docker::run { 'helloworld':
  image   => 'ubuntu:precise',
  command => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
  restart => 'always',
}

For some reason restart (and maybe other parameters) seems to be the key to triggering this problem. Once you apply this you're probably going to see Param changed or No changes detected. Tweak the image tag and you'll see it continues to output No changes detected. Then finally, remove the stderr.to_s == '' check and observe that it correctly stops and starts the container with the new parameters.

puppetlabs-docker/lib/puppet/functions/docker_params_changed.rb

Line 81 in 998d11d

if stderr.to_s == '' && status.to_s.include?('exit 0')

[cedws]

Also, running Puppet as a service seems to be critical here. If I run puppet agent or puppet apply in a shell then it works properly, even if unset HOME. So be sure to run the agent as a systemd service and then apply the code by sending SIGUSR1.

Edit: That was nonsense, I was running Puppet with sudo which means it is executed with a separate environment where HOME is set.

[sdinten]

Got to reproduce the error, see below for the output. Running this with $HOME set gives the same result except for the warning message with docker ps -a.

To summarize, when adding restart => 'always', to the pp file:

• puppet logs No changes detected
• but it will create the container (with RestartPolicy always)
• and it does not create the systemd service as it would when not adding restart => 'always',

I'll look into this once the kids are sleeping (8 pm "ish" CET) ;)

root@ubutst:/root/puppet# puppet apply -t add.pp
Info: Loading facts
Info: Loading facts
Info: Loading facts
Notice: Compiled catalog for ubutst.home.vandinten.nl in environment production in 0.51 seconds
Info: Applying configuration version '1627316102'
Notice: No changes detected
Notice: /Stage[main]/Main/Docker::Run[helloworld]/Notify[docker_params_changed]/message: defined 'message' as 'No changes detected'
Notice: Applied catalog in 0.41 seconds
root@ubutst:/root/puppet# docker ps -a
WARNING: Error loading config file: .dockercfg: $HOME is not defined
CONTAINER ID   IMAGE            COMMAND                  CREATED         STATUS         PORTS     NAMES
6e4d76e1c034   ubuntu:precise   "/bin/sh -c 'while t…"   4 seconds ago   Up 3 seconds             helloworld
root@ubutst:/root/puppet# cat add.pp
class { 'docker':
  manage_package              => false,
}

docker::run { 'helloworld':
  image   => 'ubuntu:precise',
  command => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
  restart => 'always',
}
root@ubutst:/root/puppet# env|grep HOME
root@ubutst:/root/puppet#

[sdinten]

@cedws I think I have found why this is not working for you. I agree that in your setup the error message (WARNING: Error loading config file: .dockercfg: $HOME is not defined) occurs when you run HOME= docker inspect helloworld but I think it is not relevant to why your problem occurs.

Looking at the documentation; https://forge.puppet.com/modules/puppetlabs/docker (search for 'run includes a number of optional parameters'). The restart parameter is not a valid parameter, also looking into the code:

puppetlabs-docker/manifests/run.pp

Line 10 in 998d11d

# If you want a normal named container with an init script and a restart policy

it states to use the extra_parameters to define the restart policy.

Further down in the if statement where docker_params_changed is called restart is not part of the hash of parameters to be checked, if you use extra_parameters instead it will be in the $run_with_docker_command variable and the function will detect the change.

puppetlabs-docker/manifests/run.pp

Line 455 in 998d11d

$docker_params_changed_args = {

It would have helped to have more clear error messaging, maybe you can raise a separate issue for this.

Using the below definition (both with and without $HOME set) the resources are created/changed correctly, removal works as well when adding ensure => absent,

class { 'docker':
  manage_package              => false,
}

docker::run { 'helloworld':
  image            => 'ubuntu:precise',
  command          => '/bin/sh -c "while true; do echo hello world; sleep 1; done"',
  extra_parameters => ['--restart=always'],
}

[cedws]

Hey @sdinten, apologies for the delayed response.

Indeed, removing restart seems to solve the problem! The code appears to take a completely different approach to managing containers if this is passed in for reasons I don't fully understand. But, would you agree that this is a workaround? My impression is not that we are using restart incorrectly, but rather that restart is triggering the original bug. Please correct me if I'm mistaken.

The omission in the docs you mention could be a mistake I think. On that same page is a snippet which shows restart passed in to Docker::Run:

docker::run { 'helloworld':
  image => 'microsoft/nanoserver',
  command => 'ping 127.0.0.1 -t',
  restart => 'always'

Thanks again.

[sdinten]

@cedws good point

I think we could have a discussion forever about this being a bug or not ;). Based on:

• the code not implementing the restart parameter
• It feeling very natural / intuitive to use the restart parameter (next to the writer of the documentation and you, @ahoiroman raised Error: No such file or directory if restart: always is set #694 to address the same thing)

My conclusion would be that this has to be implemented in the code and the documentation has to be made consistent about the availability of this parameter.

As it is not related to this topic (Docker 20.10 doesn't let the module work) I will attempt to do this through #694.

[github-actions]

This issue has been marked as stale because it has been open for a while and has had no recent activity. If this issue is still important to you please drop a comment below and we will add this to our backlog to complete. Otherwise, it will be closed in 7 days.