docker_swarm_service overrides service settings

[benformosa]

SUMMARY

When modifying an existing Docker Swarm service, anything that is not explictly set by the module is overriden with the generally empty defaults.

It's not clear to me if this is the expected behaviour, but it is pretty surprising coming from using the Docker cli.

ISSUE TYPE

• Bug Report

COMPONENT NAME

docker_swarm_service

ANSIBLE VERSION

ansible [core 2.14.6]
  config file = /home/user/git/ansible/ansible.cfg
  configured module search path = ['/home/user/.ansible/plugins/modules', '/usr/share/ansible/plugins/modules']
  ansible python module location = /usr/lib/python3.9/site-packages/ansible
  ansible collection location = /home/user/.ansible/collections:/usr/share/ansible/collections
  executable location = /usr/bin/ansible
  python version = 3.9.16 (main, Dec 21 2022, 10:57:18) [GCC 8.5.0 20210514 (Red Hat 8.5.0-17)] (/usr/bin/python3.9)
  jinja version = 3.1.2
  libyaml = True

COLLECTION VERSION

Collection       Version
---------------- -------
community.docker 3.4.8

CONFIGURATION

CONFIG_FILE() = /home/user/git/ansible/ansible.cfg
DEFAULT_HOST_LIST(/home/user/git/ansible/ansible.cfg) = ['/home/user/git/ansible/inventory.ini']

OS / ENVIRONMENT

RHEL 8.8

STEPS TO REPRODUCE

Targets an existing Docker swarm cluster.

https://gist.github.com/benformosa/7bf92e8975dc912326a0a8f789a47c24

EXPECTED RESULTS

• Tasks Test 1 uri, Test 2 uri, Test 3 uri should all succeed
• Tasks Test 1 swarm_info, Test 2 swarm_info, Test 3 swarm_info should all have the same output

ACTUAL RESULTS

TASK [Test 1 uri - create service] ********
ok: [node1.example.com]

TASK [Get swarm info] ********
ok: [node1.example.com]

TASK [Test 1 swarm_info - Display service info] ********
ok: [node1.example.com] => {
    "msg": {
        "Configs": [
            {
                "ConfigID": "s9hhu5ddge3lqbb3n8w954jvb",
                "ConfigName": "my_nginx_index",
                "File": {
                    "GID": "0",
                    "Mode": 292,
                    "Name": "/usr/share/nginx/html/index.html",
                    "UID": "0"
                }
            }
        ],
        "Image": "library/nginx:latest",
        "Isolation": "default"
    }
}

TASK [Test 2 uri - scale with command] ********
ok: [node1.example.com]

TASK [Get swarm info] ********
ok: [node1.example.com]

TASK [Test 2 swarm_info - Display service info] ********
ok: [node1.example.com] => {
    "msg": {
        "Configs": [
            {
                "ConfigID": "s9hhu5ddge3lqbb3n8w954jvb",
                "ConfigName": "my_nginx_index",
                "File": {
                    "GID": "0",
                    "Mode": 292,
                    "Name": "/usr/share/nginx/html/index.html",
                    "UID": "0"
                }
            }
        ],
        "Image": "library/nginx:latest",
        "Isolation": "default"
    }
}

TASK [Test 3 uri - scale with module] ********
fatal: [node1.example.com]: FAILED! => {"changed": false, "content": "", "elapsed": 0, "failed_when_result": true, "msg": "Status code was -1 and not [200]: Request failed: <urlopen error [Errno 99] Cannot assign requested address>", "redirected": false, "status": -1, "url": "http://localhost/index.html"}
...ignoring

TASK [Get swarm info] ********
ok: [node1.example.com]

TASK [Task 3 swarm_info - Display service info] ********
ok: [node1.example.com] => {
    "msg": {
        "Image": "library/nginx:latest",
        "Isolation": "default"
    }
}

[felixfontein]

This is a design decision; the same is also true for the docker_container module. The modules only compare parameters that have been explicitly specified, and if they find a difference, they update the container if possible, and if it isn't possible, they recreate it, but only with the parameters explicitly specified to the module.

There are disadvantages and advantages to this; the main advantage is that if a docker_swarm_service or docker_container task (re-)creates a service/container, it is exactly as specified.

(If you use the Docker CLI to remove and re-create a service/container, you also need to specify everything you want in the re-creation command.)

[benformosa]

Thanks for the response. That makes sense.
My use case is updating a service which is created by some other mechanism, so I don't have its full specification.

I was looking at using docker_swarm_info to populate all the parameters from the current state, but it seemed like that output doesn't map nicely to the parameters in docker_swarm_service.

My solution was to just run the cli command, which is fine, it does exactly what I want.