Docker Agenda/Task list

[gundalow]

Docker Working Group

How to help

• Firstly, click the Subscribe button on the right hand side so you will see update.

• Ansible used GitHub labels to categorize Issues and PRs, therefore everything Docker related has /label/docker

• Reviewing Docker PRs is very useful

  • Actually using and testing the PRs is one of the best types of feedback we can get. Add a comment saying what you tested and how it worked: example of good testing feedback

• Adding and extending the integration tests

• What else?

How to speak to us

• Feel free to add comments on this issue
• Join us in #ansible-devel on Libera - Ansible IRC channels

[felixfontein]

I've compiled a list of PRs which aren't from team docker contributors (i.e. all except ansible/ansible#49235 and ansible/ansible#48574). Most of them look/are dead, except two docker inventory scripts.

docker_container

Both of them look dead. The first one isn't urgend anymore (since docker has been deprecated for a while and docker_container around for a while), but the PR seems to have problems; there are review comments from @chouseknecht which have never been incorporated. I guess closing it is fine, as ansible/ansible#19103 still reminds of it. The second is about adding --cpu support. The main problem with it is that the interface isn't so great. It would be nice to have an easy way to specify CPU usage which works with different docker-py / docker API versions. This is tracked in ansible/ansible#34320, and there's a related issue ansible/ansible#49008 for --cpu-rt-runtime.

• Fixes #19103 - Set Volumes field only for anonymous volumes ansible#19105 [dead]
• Added nano_cpus parameter in the docker_container.py file. ansible#38063 [essentially dead, redesign required]

docker_image

There is one PR about adding a network parameter, which looks good; it is missing some backwards compatibility stuff, and a changelog entry. If the author continues to not reply, I suggest we close this and recreate it. Anyone interested in handling this one?

• docker_image: add network parameter ansible#45127 [probably dead] (revived as docker_image: add network parameter ansible#50313)

docker_network

There are two PRs for adding two features (attachable and scope), both have conflicts and seem dead, but it should be simple to create a new PR adding both features. @DBendit are you interested in working on this?

• Add attachable parameter for Docker overlay networks ansible#35288 [probably dead]
• Add scope parameter for docker networks ansible#45552 [probably dead]

docker_service

The docker module with the most amount of issues... There's one PR fixing something, but it has conflicts and might be dead. Is anyone interested working on this PR and/or the docker_service module in general? There's a lot to do here.

• docker_service: Fix remove_orphans ansible#31305 [maybe dead] (has been replaced by fix remove_orphans using APIs exposed via AnsibleDockerClient ansible#54316)

docker connection plugin

There are two PRs for the docker connection plugin which seem to be dead. The first one is very old, and the author stated that he won't work on it anymore (i.e. definitely dead). It will require some work to rebase this, maybe it's easier to rewrite it. The second one is rather new, but the author never responded after the initial two commits. (It was created during a hackathon, @pilou- knows more.) From the looks of it, it's probably also dead. Is anyone interested in working on the connection plugin?

• Enable docker connector command override. ansible#16198 [dead]
• Add support for setting cwd in docker connection plugin ansible#46547 [probably dead]

inventory scripts

There are three inventory script related PRs. Two add a new inventory script, the third improves an existing one. AFAIK inventory scripts are dead (there is a new plugin category for this), but since I've never used one I don't know much about this. What shall we do about them?

• docker-machine: contribute docker-machine inventory ansible#23149 [dead]
• swarm: added dynamic docker swarm nodes inventory ansible#42667 [alive]
• service/stack for swarm: Docker inventory service/stack groups for docker swarm ansible#48021 [alive] (merged)

@gundalow feel free to close the dead PRs :) For the ones where I only asked a few days ago, maybe we should wait a few more days before closing them?

[felixfontein]

@akshay196 @danihodovic @dariko @DBendit @jwitko @kassiansun @tbouvet

As mentioned above, we currently have a "problem" with docker_service. Nobody from us seems to be interested in it, and there seem to be several active users which have problems (19081, 19371, 20458, 21504, 22358, 23607, 25943, 26937, 28768, 29498, 29513, 29527, 29532, 30548, 31924, 33731, 33960, 37059, 37471, 42506, 47978) which nobody tried to fix for quite some time (except ansible/ansible#31305, which looks inactive). Is anyone of you interested on working on this?

If not, we should try to look for people interested in the module. I guess the easiest way is to post an "advertisement" in each of these issues, and hope that someone there has interest in improving the situation (or at least working on a specific fix). What do you think about the following text?

Thank you for your interest in the docker_service module. Unfortunately, it is currently essentially unmaintained. If you are interested in maintaining it, or working on this (or other) bugs, please feel free to write that here and start working on it!

[DBendit]

@felixfontein Tempted as I am to jump in, I don't know that I can commit to taking over another module until I get a better idea of how it works. I do like the idea of soliciting folks reporting these issues to submit PRs at the very least. I think that trying to get issue submitters to commit to ownership of the service is a bit too aggressive, but letting them know that their issue isn't likely to get fixed if they don't fix it themselves might prompt one or two of them to action, and then we can ask if they'd like to keep contributing.

[felixfontein]

Please see ansible-collections/community.docker#4 for a release plan for community.docker.

[felixfontein]

@WojciechowskiPiotr I just saw that I never replied to your comments on the connection plugin(s) (now there are two :) ).

Python is only needed if you want to run modules (that include facts gathering) in the container. So if you use gather_facts: false and don't use modules, everything's fine. Unfortunately, even the copy module is not only an action plugin, but also a module, so effectively you can only use raw to execute commands. So yep, indeed, this isn't a really useful workaround if you don't happen to have Python inside the container. A separate module would be really helpful.

If anyone's interested in working on this, the docker_api connection plugin contains code for pushing files from and to the container using the API, these could be generalized and used by a new module.

[felixfontein]

If you have time, please take a look at the following PRs: ansible-collections/community.docker#87 ansible-collections/community.docker#89 ansible-collections/community.docker#90 ansible-collections/community.docker#93 Once these are merged, I plan to create the 1.3.0 release, which will contain some bugfixes and a bunch of new features.

[WojciechowskiPiotr]

ansible-collections/community.docker#90 is still marked as WIP

[felixfontein]

It will stop being a WIP once 87 is merged, since it contains parts of 87.

[felixfontein]

(Doesn't mean it cannot be reviewed.)

[WojciechowskiPiotr]

I handled two, let others more familiar with docker_image look at the remaining

[felixfontein]

Would be great if someone can take a look at ansible-collections/community.docker#90 (docker_image_load) so we can release a new version by Monday (that will be included in Ansible 3.1.0, to be released on Tuesday).

[felixfontein]

I would be glad if someone could take a look at ansible-collections/community.docker#105, which adds a new module docker_container_exec which allows to run commands in docker containers.

[felixfontein]

We're happy to announce that the registration (free) for the Ansible Contributor Summit is open.

Which day should you attend?

• If you are wondering what it means to "contribute" to Ansible, or if you have been using Ansible for a while and are thinking of ways to get more involved with the project and community, then Day 1 (September 28, Tuesday) is for you!
• If you have already been contributing or participating in our previous Contributor Summits, you are still welcome to attend Day 1, however we think that Day 2 (October 1, Friday) will be more interesting for you.

Refer to the registration page for details.

See you at the summit!

[felixfontein]

I suggest we drop support for Ansible 2.9 and ansible-base 2.10 in the next major release. Both will be EOL in May 2022 anyway, and some versions of both cause problems (see ansible-collections/community.docker#271). I think we should also have some policy when we drop support for ansible-core versions, and/or stop testing against them. I would suggest to strip EOL'ed ansible-core versions to minimal testing in CI (also so our CI matrix does not grow unbounded) and drop support for all EOL'ed ansible-core versions (and the ones which will EOL in the next 1-2 months) on every major release.

Does that sound reasonable? Any feedback, other ideas, ...?

(See also ansible-community/community-topics#50 for a similar discussion for community.general and community.network.)

[felixfontein]

I'm wondering a bit whether Docker SDK for Python is finally dead, now that docker-compose switched from Python to Go. PRs and issues are being ignored, PR tests are not even triggered, there haven't been commits since mid-October 2021, ... There was a similar phase some years ago, which fortunately ended, but now with Docker SDK for Python no longer being used by Docker Inc. I'm somewhat worried.

[WojciechowskiPiotr]

You mean the https://github.com/docker/docker-py or a different project?

[felixfontein]

Yes, that's the (official) Docker SDK for Python.

[felixfontein]

docker/docker-py#2989 is a PR for an umaintained notice in Docker SDK for Python 😞

[felixfontein]

I created an issue for discussing the future of the collection: ansible-collections/community.docker#364

[felixfontein]

I'd like to deprecate Python 2.6 support: ansible-collections/community.docker#388 Is anyone opposed to this?

[samccann]

@felixfontein since we will be archiving/freezing the ansible/community repo, can you move any further discussions like this to the forum and close out this issue?

[felixfontein]

Moving this to the forum doesn't make too much sense to me right now, since there's no tag / category for this (yet). I created a new topic in the community.crypto repository, ansible-collections/community.crypto#24. Anyone interested in this topic, and general discussion about community.docker, should subscribe to that issue!

I'm closing this one now; there's no open discussion in here (in fact the last discussion has been some time ago). Thanks for everyone involved here who's no longer interested in following in the new topic, and I'm happy to see the ones that have continued interest in the collection in ansible-collections/community.docker#701 or somewhere else instead :)

(For anyone who didn't knew yet: there's the new Ansible forum, a discourse-based forum for the Ansible community. This can be used for support question, project discussion, information about Ansible related events, and anything else that's somehow related to Ansible. If you haven't already, please sign up! :) )