docker_swarm_service update behavior is unexpected

[jimrobinson]

Summary

I'm unsure of this is a bug or not, it's certainly not acting as I would have expected it to. Say I have a stack named ib, containing three services, db, ibeam, and ibexecution:

$ docker stack ls
NAME        SERVICES   ORCHESTRATOR
ib          3          Swarm

$ docker stack ps ib
ID             NAME               IMAGE                                    NODE                    DESIRED STATE   CURRENT STATE                ERROR     PORTS
mqlu08jbwzj2   ib_db.1            registry.example.org/mariadb:10.5        docker-01.example.org   Running         Running about a minute ago
59d4b5o7zr9r   ib_ibeam.1         registry.example.org/ibeam:v0.4.2        docker-01.example.org   Running         Running about a minute ago
dj2jyu0cpsz0   ib_ibexecution.1   registry.example.org/ibexecution:1.0.0   docker-01.example.org   Running         Running about a minute ago

Then I can, if I need to, restart a service using the command "docker service update --force". An example of restarting the ib_ibeam service by command line:

$ docker service update --force ib_ibeam
ib_ibeam
overall progress: 1 out of 1 tasks
1/1: running
verify: Service converged

$ docker stack ps ib
ID             NAME               IMAGE                                    NODE                    DESIRED STATE   CURRENT STATE             ERROR     PORTS
mqlu08jbwzj2   ib_db.1            registry.example.org/mariadb:10.5        docker-01.example.org   Running         Running 3 minutes ago
9x87w9i86m19   ib_ibeam.1         registry.example.org/ibeam:v0.4.2        docker-01.example.org   Running         Running 14 seconds ago
59d4b5o7zr9r    \_ ib_ibeam.1     registry.example.org/ibeam:v0.4.2        docker-01.example.org   Shutdown        Shutdown 14 seconds ago
dj2jyu0cpsz0   ib_ibexecution.1   registry.example.org/ibexecution:1.0.0   docker-01.example.org   Running         Running 3 minutes ago

$ docker service ps ib_ibeam
ID             NAME             IMAGE                               NODE                    DESIRED STATE   CURRENT STATE             ERROR     PORTS
9x87w9i86m19   ib_ibeam.1       registry.example.org/ibeam:v0.4.2   docker-01.example.org   Running         Running 25 seconds ago
59d4b5o7zr9r    \_ ib_ibeam.1   registry.example.org/ibeam:v0.4.2   docker-01.example.org   Shutdown        Shutdown 25 seconds ago

$ docker stack rm ib
Removing service ib_db
Removing service ib_ibeam
Removing service ib_ibexecution
Removing network ib_default

You can see from this capture that ib_ibeam always remained part of the 'ib' stack through the restart. When I removed the ib stack the three services were removed.

Looking over the ansible modules I thought that community.docker.docker_swarm_service was the module that would let me perform a similar task:

- name: "restart ib_ibeam if cacert.jks was updated"
  community.docker.docker_swarm_service:
    name: "ib_ibeam"
    # docker_swarm_service is insisting I specify an image for some reason
    image: "{{ images[env].ibeam }}"
    force_update: true
  when: " ... various criteria  elided ... "

This does not have the result I was expecting. As far as I can tell what it is doing is shutting down ib_ibeam within the ib stack and then starting up an independent service named ib_ibeam (but which is not part of the ib stack):

$ docker stack ps ib
ID             NAME               IMAGE                                    NODE                    DESIRED STATE   CURRENT STATE            ERROR     PORTS
t91gimc6r58q   ib_db.1            registry.example.org/mariadb:10.5        docker-01.example.org   Running         Running 52 seconds ago
783dj70v7yom   ib_ibeam.1         registry.example.org/ibeam:v0.4.2        docker-01.example.org   Shutdown        Shutdown 7 seconds ago
at87irkads11   ib_ibexecution.1   registry.example.org/ibexecution:1.0.0   docker-01.example.org   Running         Running 52 seconds ago

$ docker service ls
ID             NAME                MODE         REPLICAS   IMAGE                                        PORTS
sqkbo6zmqh1s   ib_db               replicated   1/1        registry.example.org/mariadb:10.5
1zjm8x9u5cb1   ib_ibeam            replicated   0/1        registry.example.org/ibeam:v0.4.2
j6whrs5nifc8   ib_ibexecution      replicated   1/1        registry.example.org/ibexecution:1.0.0

$ docker stack rm ib
Removing service ib_db
Removing service ib_ibexecution
Removing network ib_default

$ docker service rm ib_ibeam
ib_ibeam

I can work around the issue by just using ansible.builtin.command to execute the "docker service update --force ib_ibeam" command, but I wanted to ask if it's expected that the docker_swarm_service behave this way?

Issue Type

Bug Report

Component Name

community.docker.docker_swarm_service

Ansible Version

$ ansible --version
ansible [core 2.13.1]
  config file = /home/jimr/proj/cdm/ansible/ansible.cfg
  configured module search path = ['/home/jimr/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /home/jimr/proj/cdm/ansible/venv/lib64/python3.10/site-packages/ansible
  ansible collection location = /home/jimr/.ansible/collections:/usr/share/ansible/collections
  executable location = /home/jimr/proj/cdm/ansible/venv/bin/ansible
  python version = 3.10.7 (main, Sep  7 2022, 00:00:00) [GCC 12.2.1 20220819 (Red Hat 12.2.1-1)]
  jinja version = 3.1.2
  libyaml = True

Community.general Version

$ ansible-galaxy collection list community.general

# /home/jimr/proj/cdm/ansible/venv/lib/python3.10/site-packages/ansible_collections
Collection        Version
----------------- -------
community.general 5.3.0  

# /home/jimr/proj/cdm/ansible/venv/lib64/python3.10/site-packages/ansible_collections
Collection        Version
----------------- -------
community.general 5.3.0  

Configuration

$ ansible-config dump --only-changed
ANSIBLE_PIPELINING(/home/jimr/proj/cdm/ansible/ansible.cfg) = True
DEFAULT_VAULT_PASSWORD_FILE(/home/jimr/proj/cdm/ansible/ansible.cfg) = /home/jimr/.config/ansible/vault.key
HOST_KEY_CHECKING(/home/jimr/proj/cdm/ansible/ansible.cfg) = False
PERSISTENT_CONNECT_TIMEOUT(/home/jimr/proj/cdm/ansible/ansible.cfg) = 60

OS / Environment

• Fedora release 36 (Thirty Six)
• Linux 5.19.14-200.fc36.x86_64
• x86_64

Steps to Reproduce

The following is a minimal playbook that mocks up the scenario, and does appear to behave the same way as my real life instance.

- name: "deploy simulations"
  hosts: "docker_swarm"
  remote_user: "root"
  tasks:
    - name: "deploy stack"
      community.docker.docker_stack:
        state: "present"
        name: "ib"
        compose:
          - version: "3.7"
            services:
              ibeam:
                image: "alpine:latest"
                command: "sleep infinity"
                environment:
                  SERVICE: "ibeam"
              ibexecution:
                image: "alpine:latest"
                command: "sleep infinity"
                environment:
                  SERVICE: "ibexecution"
              db:
                image: "alpine:latest"
                command: "sleep infinity"
                environment:
                  SERVICE: "db"

    - name: "force update ib_ibeam service"
      community.docker.docker_swarm_service:
        name: "ib_ibeam"
        # for some reason module insists on image, indicating it's not going to
        # pick that up from the stack...
        image: "alpine:latest"
        force_update: true

Expected Results

I expect the ib_ibeam service from within my stack to be restarted the same as if I issued the following from the command line:

docker service update --force ib_ibeam

Actual Results

The ib_ibeam service is shut down within the ib stack and a completely independent service named ib_ibeam (but not associated with the stack) is started.

Code of Conduct

• [X] I agree to follow the Ansible Code of Conduct