docker_container.running creates containers using the image ID as the image name

[robertodocampo]

We start containers with docker_container.running (see the sample.sls below) . When we start a container manually (or in older salt-minion versions) the container is started with several tags. One of each is the IMAGE name.

The image name in this last version is replaced by a key

CONTAINER ID IMAGE COMMAND
cb7e20f03ba5 3069a9fb302a "/watchtower --clean…"

[root@test rdocampo]#  docker inspect watchtower | grep Image
        "Image": "sha256:3069a9fb302acfc664970a4cdb962b9915f15aeb089b6216f17edcd29d5dfc80",
            "Image": "sha256:3069a9fb302acfc664970a4cdb962b9915f15aeb089b6216f17edcd29d5dfc80",

When i run my sample container manually (or older salt-minion version) the image is tagged with his real name:

CONTAINER ID IMAGE COMMAND
9b34d2322583 v2tec/watchtower "/watchtower --clean"

[root@test rdocampo]#   docker inspect watchtower | grep Image
        "Image": "sha256:3069a9fb302acfc664970a4cdb962b9915f15aeb089b6216f17edcd29d5dfc80",
            "Image": "v2tec/watchtower",

We use this name to automatically upgrade the containers when a new image is available.

Setup

Manually started container

docker run -d \
  --name watchtower \
  -v /var/run/docker.sock:/var/run/docker.sock \
  -v /root/.docker/config.json:/config.json \
  v2tec/watchtower

test.sls

watchtower:
  docker_container.running:
    - image: v2tec/watchtower:latest
    - name: watchtower
    - restart_policy: always
    - labels:
        filebeat.stdin: 'true'
    - binds:
      - /var/run/docker.sock:/var/run/docker.sock
      - /root/.docker/config.json:/config.json
      - /etc/localtime:/etc/localtime
    - command: "--cleanup --debug"

Steps to Reproduce Issue

(Include debug logs if possible and relevant.)

Versions Report

Same version on the master and minion

`
Salt Version:
Salt: 2018.3.0

Dependency Versions:
cffi: 1.11.5
cherrypy: Not Installed
dateutil: 2.7.2
docker-py: 3.3.0
gitdb: Not Installed
gitpython: Not Installed
ioflo: Not Installed
Jinja2: 2.10
libgit2: Not Installed
libnacl: Not Installed
M2Crypto: 0.28.2
Mako: Not Installed
msgpack-pure: Not Installed
msgpack-python: 0.5.6
mysql-python: Not Installed
pycparser: 2.18
pycrypto: Not Installed
pycryptodome: 3.6.1
pygit2: Not Installed
Python: 2.7.5 (default, Feb 20 2018, 09:19:12)
python-gnupg: Not Installed
PyYAML: 3.11
PyZMQ: 17.0.0
RAET: Not Installed
smmap: Not Installed
timelib: Not Installed
Tornado: 4.2.1
ZMQ: 4.1.6

System Versions:
dist: redhat 7.5 Maipo
locale: UTF-8
machine: x86_64
release: 3.10.0-693.21.1.el7.x86_64
system: Linux
version: Red Hat Enterprise Linux Server 7.5 Maipo
`

Thanks a lot

[garethgreenaway]

@robertodocampo Thanks for the report. I was able to reproduce this and I didn't see it happens in 2017.7.
@terminalmage thoughts on this one?

[terminalmage]

This was due to a change in how we handle image names. Rather than trying to parse the image name and tag, we resolve that image name and tag by inspecting it and grabbing the image ID. We then pass that ID as the image when creating the container. While this allows us to elegantly handle a wide range of image name syntaxes, I can see how not having the image name in the metadata is not user-friendly, so I'll get this changed.

[terminalmage]

#47367 resolves this.

[rallytime]

Closed via #47367