community.docker icon indicating copy to clipboard operation
community.docker copied to clipboard

docker_swarm_service overrides service settings

Open benformosa opened this issue 1 year ago • 2 comments

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"
    }
}

benformosa avatar Jun 19 '23 09:06 benformosa

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.)

felixfontein avatar Jun 20 '23 06:06 felixfontein

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.

benformosa avatar Jun 20 '23 06:06 benformosa