What is needed to make this collection viable?

[rhatdan]

Should the collection be able to manage containers.conf? registries.conf? policy.conf? storage.conf? For rootfull and rootless users? Or should this be handled in a different tool/collection?

How does this collection compare to the ansible-docker-collection?

What commands are missing? What help is needed to complete the collection?

Should this collection go for formal support?

[rhatdan]

@jwhonce @baude @mheon @fatherlinux FYI

[sshnaidm]

Well, I think I can start answering so we can discuss it.

1. What is needed to make this collection viable?
Probably we'll need to have some vision of the future of this collection. I hope it's a little viable even now, we use some modules in Openstack, users open issues in this repo, send patches. So I think it's not completely useless and has some value. Perhaps we can discuss how to make it more robust, solid and useful. How we can improve user experience, make it more familiar in the community and "productize" it.

[sshnaidm]

2. Should the collection be able to manage containers.conf? registries.conf? policy.conf? storage.conf?

This is a great question. I think the possibility to manage easily configurations files will help to improve user experience significantly. Currently Ansible has a module to modify INI file, also it's possible to modify JSON and YAML files with some tricks and update_fact_module. But most of containers config files are TOML files and INI module may not handle it very well.
So the options I have in my mind are:

1. Writing Ansible module that modify TOML format files by analogy to INI modifying module. It doesn't make sense to do something containers specific, since it's a standard TOML format and also it can be useful for all other community. We can place it in ansible.utils or community.general collection for everyone and have examples for its usage for containers configurations in this repo.
2. To use Ansible modules like lineinfile, blockinfile and others, but it's usually string/regex search based, so it's not really a robust way to modify configuration files.

Personally I'd prefer an option 1 as it will do the best job and will contribute to whole community as well.
P.S. Maybe it's fine also to revive a json_patch module and help to merge it to community collection, it's kinda stuck in Ansible. Probably it's better way to modify JSON files (for policy.json).

[sshnaidm]

How does this collection compare to the ansible-docker-collection?
My intention was to make Podman collection as much as possible close to Dockers one, while to keep and support all Podman unique features.
So about coverage of docker modules, what we don't have yet (and not related to docker-compose or Docker Swarm):

• current_container_facts – Return facts about whether the module runs in a Docker container
• docker_host_info – Retrieves facts about docker host and lists of objects of the services.
• docker_container_exec – Execute command in a docker containe
• docker_prune – Allows to prune various docker objects

This is not much and can be completed easily.
We also have Podman specific modules that Docker Ansible collection doesn't have. About running docker-compose files with Podman I have an issue to investigate and see if we can support it.

We don't have 1:1 format match in output and some of our modules can have different input options. So I can't say it's 100% compatible, but main modules like podman_container are close to it. I've also started discussion about choosing the best approach to keep Podman module compatible with Docker ones. There is a work that should be done and some issues are opened about it.
Best start here will be the discovery of differences in input/output between parallel modules in Docker and Podman collections and filling them up step by step.

[sshnaidm]

What commands are missing?

So, I think I covered up most of commands. We don't have yet commands except of docker commands above:
commit, diff, exec, generate kube, healthcheck, info, kill, manifest, mount, system, unshare. Probably not all of them should be Ansible modules, it's discussable.
In addition to that, podman_image module should be rewritten from scratch.

What's else should be done is support for working with Podman Python API. Currently I'm working in a background on alpha support for podman_container module: #267
The problem is that podman-py is not really viable now, its new version lacks a lot of features and not all of them work, and not all of them work as expected. Unfortunately it's not capable for production usage now, so I had to re-implement it in the collection itself (#267)
I hope when podman-py will be ready, we can switch to it easily, I try to keep my commands exactly as it's there.

[fatherlinux]

I would think it would also be useful to have "generate systemd" as well as the ability to load that systemd unit file and start/stop the service.

…

On Thu, Sep 23, 2021, 12:30 PM Sergey ***@***.***> wrote: *What commands are missing?* So, I think I covered up most of commands. We don't have yet commands except of docker commands above: commit, diff, exec, generate kube, healthcheck, info, kill, manifest, mount, system, unshare. Probably not all of them should be Ansible modules, it's discussable. In addition to that, podman_image module should be rewritten from scratch. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#307 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAA4WZKYY7AJ26AZGHQIE7TUDNI3HANCNFSM5EPDNABA> .

[sshnaidm]

We have "generate_systemd" feature for pod and containers, covered it in last patches: #298 #299
For starting and stopping systemd services one can use a usual Ansible module systemd.
Like this for example:

- name: Run and enable systemd service for redis container
  ansible.builtin.systemd:
    name: redis-container
    state: started
    enabled: yes

[sshnaidm]

What help is needed to complete the collection?
Should this collection go for formal support?

I combined these two questions together since it's related.
I think we should have this collection going for formal support, it should be part of Automation Hub and supported in Red Hat. I've been in contact with Ansible folks about it and know what should be done technically (I have the same for Openstack collection). The most challenging will be organizational question, please contact me privately for the details.

So, yes, I think it should more that one guy that works on this collection in his free time. I try to keep up with issues and maintenance, while don't have much time for investigations and developing new features. Currently I'm not backed by the company, and I think this collection deserves much more effort and time! So more people are required to work on it.

Ideally it would be a supported product, with upstream in Galaxy as it's now and downstream supported version in Automation Hub, when it's available for a subscription for paid customers.