Podman compose

At pulpcon we got some feedback about pulp installation and how it is challenging to understand what the installer is doing.

A podman-compose seems to be more readable and easier to understand, so I
got the images from pulp-operator, and started this PoC: https://github.com/pulp/pulp-operator/pull/310

We will keep working on improving the other installers (single container, pulp_installer collection, and pulp-operator), but we would like to hear from pulp community if this podman-compose can improve the experience of installing pulp?


Personally I have never liked/understood the point of (excuse my nomenclature) docker-compose.
For very simple things I cut out that middle man and just call container commands with a shell script, and for more complicated things I prefer the Ansible middle man. I guess I need to use Ansible on a daily basis anyway, so docker-compose is just another tool asking me to learn it’s personal YAML syntax, albeit one I can easily avoid using…

1 Like

I like the idea! So far, we are using the all-in-one pulp container image because we do not have a container platform yet.

What about using podman generate and podman play instead of podman-compose?
(Moving from docker-compose to Podman pods)


On a related note, I initially test my container builds with https://github.com/Kong/docker-pulp/blob/main/docker-compose.yml

Someday I should figure out how to properly create volumes, and also update to a “current not Redis queue” Pulp version… Right now it’s “mkdir .volume && chmod 999 .volume”. :confused:


This is pretty interesting, never heard about podman generate/play before,
I’ll test it and see if I can get pulp running easily.

Since we are talking about pods, @keilr have you tried pulp-operator?

Thanks for sharing! It is way better than my podman-compose, @mcorr I think we could add some note here mentioning Kong’s docker-compose

1 Like

Hey @dannysauer

I have one question: do you have a rough estimate of how often the Pulpcore version is bumped ? I see that it is currently on 3.15.

We generally try to stay within roughly one major version of current. I slacked a little the last month or two with holiday change moratoriums, so that’s drifted a bit more than I wanted (specifically because I wanted sufficient time to test how migration to the new worker system works) – but I’m actively bringing that back up to date now.

The goal is to have fully automated updates in that repo so ultimately we’ll stay in sync with whatever is on pypi. I have automated updates and deployments working for the python dependencies, but don’t have it properly automated for pulpcore or the content modules because of the way they’re interdependent… And because of our lack of more thorough automated checkout testing. I have a plan for fixing that and it’s scheduled for “sometime in the next couple of months,” but good testing automation takes time. :slight_smile:

1 Like