Open lmergner opened 3 years ago
docker plugin
throws an error when it tries toset
an activated plugin. If a plugin already exists, but you haveplugin_options: {<options>}
in the task, it will fail instead of modifying the plugin.
I'm not sure whether it should dis- and then afterwards re-enable the plugin in this case (or allow to configure that behavior), or just fail more gracefully. (I don't use Docker plugins myself.)
Being able to configure this behavior (potentially three options: a) fail, b) just don't configure, c) disable, configure, and then re-enable) is probably the best thing (with whatever default makes most sense for plugins in general). If you're interested in implementing this, feel free to submit a PR!
It's also unclear from the docs whether I need to install (
state: present
) before I enable (state: enabled
) a plugin using ansible. If I enable it, does the module also install it?
If you enable it and it is not installed, it first installs it and then enables it: https://github.com/ansible-collections/community.docker/blob/f01dacd6cf87912a418248e6e7ff640f066d23d6/plugins/modules/docker_plugin.py#L309-L316
This might be a reason to have a
docker_plugin_info
since, using ansible, I cannot readdocker plugin ls
— anddocker_host_info
does not include a section for plugins.
That would be nice indeed. If you want to contribute such a module, or extend docker_host_info
to return that information, PRs are welcome.
@felixfontein My issue is that it doesn't check to see whether the plugin settings need to be be changed - so it'll work the first time, and then fail on subsequent runs as it's unnecessarily trying to update the settings on an active plugin. I think I'd need a different play for updating a plugin settings, as it's not always possible to disable a plugin - it's very possible it's in use, so I'd need to scale down the services referencing it, and then disable it, update the setting, and then scale up the services again... not as trivial as you think
Adding on to this report, I'm experiencing a similar issue (ironically with the same plugin). I dynamically generate the plugin settings at runtime based on my inventory, thus changing my inventory changes the settings of the plugin. When I run this module, it does not update the settings of the plugin but instead of erroring or warning it reports no changes. I'm not sure what the proper behavior should be in this case, but silencing this desired diff seems unideal.
Example scenario and code:
# inventory_1.yaml
storage:
hosts:
data01:
data02:
# inventory_2.yaml
storage:
hosts:
data01:
data02:
data03:
# playbook.yml
- name: Configure storage pool
hosts: storage
tasks:
- name: Install glusterfs plugin
community.docker.docker_plugin:
alias: "storage"
plugin_name: docker.io/mochoa/glusterfs-volume-plugin
state: enable
plugin_options:
SERVERS: "{{ groups['storage'] | join(',') }}"
Running ansible-playbook playbook.yml -i inventory_1.yaml
results in no errors and hosts data01
and data02
being configured with 'SERVERS':'data01,data02'
.
Then running ansible-playbook playbook.yml -i inventory_2.yaml
also results in no errors, but data01
and data02
are still configured with 'SERVERS':'data01,data02'
and data03
is configured with 'SERVERS':'data01,data02,data03'
. I would expect some indication from this module that either an update needs to occur but is not possible or that the current state at least does not match the desired state.
Hmm, this looks more like a problem with the docker.io/mochoa/glusterfs-volume-plugin plugin to me. Apparently the module was able to tell the plugin to update, since data03
is there and has the new value, but the plugin didn't update data01
and data02
.
The module does not know anything about what the plugin does, so it has to rely on the plugin to correctly update its state somehow.
SUMMARY
docker plugin
throws an error when it tries toset
an activated plugin. If a plugin already exists, but you haveplugin_options: {<options>}
in the task, it will fail instead of modifying the plugin.It's also unclear from the docs whether I need to install (
state: present
) before I enable (state: enabled
) a plugin using ansible. If I enable it, does the module also install it?This might be a reason to have a
docker_plugin_info
since, using ansible, I cannot readdocker plugin ls
— anddocker_host_info
does not include a section for plugins. If I know which plugins are installed and enabled, we can conditionally install, disable, reconfigure, etc. Usingcommand: docker plugin ls
is a bit of an anti-pattern isn't it?ISSUE TYPE
COMPONENT NAME
community.docker.docker_plugin
ANSIBLE VERSION
COLLECTION VERSION
CONFIGURATION
OS / ENVIRONMENT
Darwin mergner-air 19.6.0 Darwin Kernel Version 19.6.0: Mon Apr 12 20:57:45 PDT 2021; root:xnu-6153.141.28.1~1/RELEASE_X86_64 x86_64
STEPS TO REPRODUCE
Here is an example which requires plugin_options, but even the docker docs use sshfs which could take DEBUG=1 option
EXPECTED RESULTS
ACTUAL RESULTS