How to replace the "podman generate systemd" command since its deprecated

[Pamalosebi]

The description states simply "Use Quadlet for running containers and pods under systemd.".
tldr: Please tell me how to replace "podman generate systemd" in my environment.

In my current setup, I have Podman installed on several hosts, along with podman-compose. The entire setup runs under a rootless user configuration, with all containers operating as rootless as well. I have created a podman-compose.yml file fitting to my use cases and requirements.
Once everything is configured properly and the containers are running smoothly with podman-compose, I use the following script to generate systemd service files for the containers created through podman-compose:

#!/bin/bash

# The directory for systemd user services
SYSTEMD_USER_DIR=$HOME/.config/systemd/user

# Create the systemd user services directory if it doesn't exist
mkdir -p "$SYSTEMD_USER_DIR"

# remove all old entries
rm -rf "$HOME"/.config/systemd/user/*

# Get the names of the running Podman containers
CONTAINER_NAMES=$(podman ps -a --format "{{.Names}}")

# Generate and overwrite the systemd files for each container
for CONTAINER_NAME in $CONTAINER_NAMES; do
  echo "Generating systemd file for $CONTAINER_NAME"

  # Generate the systemd service file for the Podman container
  podman generate systemd -t 5 "$CONTAINER_NAME" > "$SYSTEMD_USER_DIR"/"$CONTAINER_NAME".service

  # Reload the systemd daemon
  systemctl --user daemon-reload

  # Enable the new service
  systemctl --user enable "$CONTAINER_NAME".service
done

I've been using Podman for a long time, especially appreciating the "podman generate systemd" command. The last update seem to move away from this key feature. I checked out Quadlet, but it doesn’t match the functionality and flexibility I'm used to. I don't want to write for every single container a Quadlet file and maintain it.

I really like Podman, but the change might force me to consider switching to something else... maybe Docker. I'm open to Quadlet or other alternatives if they can cover the same ground. Is there something I've missed or another way to maintain the functionality I need within Podman's ecosystem? Can I automatically create Quadlet files somehow ?

[eriksjolund]

Maybe the command podlet could be useful?
https://github.com/k9withabone/podlet
It looks like podlet can transform a podman run command into a container unit.

[groovyman]

Thank you, but in this case you should give the maintainer of Fedora an hint, that they should also ship this tool in their Fedora F39 distribution. Currently, there is a gap due to the removal of the absense of the podman generate systemd command.

[Pamalosebi]

Thank you @eriksjolund

This would sound promising:

Convert a (docker) compose file to:
Multiple quadlet files

But then a little further down they state:

When converting compose files, not all options are supported by podman/quadlet. This is especially true when converting to a pod as some options must be applied to the pod as a whole. If podlet encounters an unsupported option an error will be returned. You will have to remove or comment out unsupported options to proceed.

I would have to put a lot of time and effort in this now... while it was super simple and reliably before.

Actually we wanted to discuss using Podman for my business projects. We've begun some test projects with it, but I'll have to stop these efforts next week. I just don't see how I could manage a big number of containers (and how they are geared together) using Quadlet files.

[rhatdan]

We are not suggesting that you drop compose and move to quadlet, we are suggesting that for standard containers running under systemd, that people use quadlet.

You seem to have a unique case here that we would like to discuss perhaps at a community cabal meeting.
@vrothberg WDYT?

[vrothberg]

I miss exact requirements. The description is very high level. @Pamalosebi, can you elaborate what is missing exactly?

I personally think that writing a .container file once is less work than creating a container manually and then scripting around podman-generate-systemd to generate the units. But I may be missing something crucial in your use case.

[Pamalosebi]

Quadlet requires users to create and manage multiple files (.container, .network, .volume) for each container.
This becomes much more complex and difficult to manage, especially if you have a large number of containers.
This also affects versioning and updates. A single compose-file previously made project tracking straightforward.

I am familiar with podman generate and the transition and effective use of quadlets will take time and testing.

Then one of the first points in the documentation is that when a quadlet is started, Podman often pulls new container images.
which can take a long time. Maybe a manual pre-pull of the images can help here... but it was not needed before.

I chose Podman for its simplicity over more complex solutions like k8s or k3s.
I suggest introducing a command like podman generate quadlet (which generates quadlet files and configs from an running podman project) to ease the transition and keep the simplicity that Podman offers.

[vrothberg]

As mentioned above, there is a project to generate Quadlets: https://github.com/k9withabone/podlet

I do not want to add that functionality to Podman as the ultimately goal is to move away from the workflow of generating systemd units based on existing containers. With Quadlet we aim at a Compose and K8s-like declarative workflow. Adding podman generate quadlet conflicts with that goal and it would imply that new Quadlet features had to be added there as well.

The current strategy is to deprecate podman generate systemd. That means that no new features will be added to generate systemd but only bug fixes.

[Pamalosebi]

the ultimately goal is to move away from the workflow of generating systemd units based on existing containers

ok... well, I don't have to understand everything. I just don't see the advantage for your users.

[vrothberg]

Maybe it doesn't fit your use case which is OK. Where I see the advantage is the reduced/improved workflow.

Previously, the worklflow roughly looked as follows:

1. Create a container on the CLI
2. Run podman generate systemd
3. Install the unit file(s)
4. Reload the daemon + Start

After an update to Podman, the entire process had to be repeated in case there were fixes to podman generate systemd.

With Quadlet, the workflow is reduced to installing the files and reloading the daemon and starting the service. Services may also start automatically on boot. After updates, nothing has to be changed or done by the user. The underlying units are transparently generated by Quadlet.

Update: That means the responsibility of fixing potential issues in the generated units is not on the user.

[Pamalosebi]

OK. For the absolute basic standard user, this seems better.
Unfortunately, it kills `podman-compose' and indeed long working setups.

[vrothberg]

Quadlet originates from the automotive teams which I do not consider to be standard users. It addresses real needs and long-standing workflow issues we've been hearing from users.

Unfortunately, it kills `podman-compose' and indeed long working setups.

Can you elaborate on that? I do not see how it would impact podman-compose since Quadlet focuses on running containers under systemd which isn't something Compose addresses.

[nivekuil]

+1 for the use case of converting "podman [pod] run" to systemd units. I was planning to just roll my own systemd generator since the rate of breakage in podman is quite high in general; going by the pattern quadlet will probably be deprecated in 2-3 years.

[rhatdan]

That seems a little harsh. We believe we built a better way to run podman containers under systemd, and want to deprecate a different way the Podman can do it.

[nivekuil]

not saying quadlet isn't better for podman, but podman itself seems to prioritize being an application more than a platform. Giving users good stuff faster isn't necessarily a bad thing, but there's inevitably some tension here with stability.

[rhatdan]

Well stability has not been broken, since we gave you a warning, if there is sufficient warning and push back, it could be reconsidered.

[nivekuil]

not broken, but in tension. That tension provoked this discussion: how should users building tools atop podman respond to this warning? That's the topic at hand, and my advice to @Pamalosebi is that long term it's better to reduce reliance on podman. That's true for any dependency of course, but I would feel a lot better about relying on systemd directly here than the new podman-specific way to do it.

[Pamalosebi]

I thought about it the last few days. When the whole wave of frustration calmed down.
I think my way in the future will be to write systemd service files manually.

Something like:

# <container-name>.service

[Unit]
Description=Podman service for running <container-name>
Documentation=https://docs.podman.io/en/latest/index.html
Wants=network-online.target
After=network-online.target
RequiresMountsFor=/run/user/<user-id>/containers

[Service]
Environment=PODMAN_SYSTEMD_UNIT=%n
User=<username>
Group=<groupname>
Restart=on-failure
TimeoutStopSec=65
ExecStart=/usr/bin/podman start <container-name>
ExecStop=/usr/bin/podman stop -t 5 <container-name>
PIDFile=/run/user/<user-id>/containers/overlay-containers/<container-name>/userdata/conmon.pid
Type=forking

[Install]
WantedBy=default.target

Maybe I could take this a bit further... and take the "container-name" directly from the compose files. Also the user ID.
Then it would just be a tiny tweak to my previous script since the service files are generated automatically again.

That doesn't mean I'm happy about the change. It's just the way to keep working with podman.
Personally, I can't see the advantage of quadlets (for my usecase!)... So, I try to work around it.

[rugk]

I basically have the same question, I just also use https://github.com/containers/podman-compose. And I would love to deprecate that and move to Quadlet as that sounds very good for my use case. (I have just read about it.)

Actually, let's see my current process…

Current process

I write docker-compose.yml files as I think they are the most portable (and not as complicated as Kubernetes YAMLs and well I have not learned the latter and think it/a kubernetes cluster is "too much" for my use-case). Anyway, I use these and start it via https://github.com/containers/podman-compose. That works, except that podman-compose project seems understaffed, had (IMHO unexpected) big breaking changes (ref containers/podman-compose#504) and generally slow updates, so is is quite unstable. That is why I would have no problem with moving to an officially supported way like Quadlets. Especially as I think running these via systemd seems a slim enough (stack), as I have been afraid of Kubernetes for now.
Anyway, my process is not finished, because now here comes the question. I have, after having these containers up and running, of course used podman generate systemd to generate systemd units and then I did not have to run podman-compose anymore, except for when I wanted to change the setup.

So the process was like this, in short: docker-compose.yml -> podman-compose up -> podman generate systemd.
As such, as I end up with systemd unit files anyway, you may see why I would like to switch to Quadlets.

What I want

Now, what is the migration path here?
Is there an podman generate quadlet (have not seen it)? Or can I use podman generate kube and then generate a Quadlet out of the kube file(s)?

That would be awesome, because then I could switch to that and convert/keep my current configuration.

[Pamalosebi]

@rugk

And BTW my main reason for not using docker (compose) is I don't want a rootfull daemon, and podman is made for that while being compatible quite much.

Just saying... in case of emergency this is a thing: https://docs.docker.com/engine/security/rootless/

@vrothberg

I mentioned it already but I want to reiterate: there are no plans to remove podman-generate-systemd, so you can just continue using that. Migrating to Quadlet is recommended but it is not enforced.

Okay, its just so that everytime I execute "podman generate systemd" I get:

DEPRECATED command:
It is recommended to use Quadlets for running containers and pods under systemd.

Please refer to podman-systemd.unit(5) for details.

Nobody should continue to build on top of this feature.¯\_(ツ)_/¯

[vrothberg]

Nobody should continue to build on top of this feature.¯_(ツ)_/¯

Do you have an alternative idea how to notify/incentivize users to migrate to Quadlet? The warning is emitted on stderr to avoid breaking automation scripts that may parse stdout.

[Pamalosebi]

I used the weekend to implement / replace the "podman generate systemd" fully with Ansible.
Therefore I am not using the function anymore as it is natively implemented and I can keep working as it is.
Even if the project decides it is time to remove it.

Do you have an alternative idea how to notify/incentivize users to migrate to Quadlet?

No, it is good that it is very present. And then everyone can solve it the way they want to.

I mean... everything else about podman is working like a charm. Thank you for your work on Podman.

[vrothberg]

I used the weekend to implement / replace the "podman generate systemd" fully with Ansible.

Did you use the Ansible System Role for Podman? The latest version of it supports Quadlet as well.

[Pamalosebi]

Hmm... no. I just used containers.podman.podman_container_info to exract the podman container ID.
Which is used in the service files to manage the containers.

[DaveWK]

I read through all the previous discussion, but don't see a clear "call to action" here -- as an end user of podman, when I call podman generate systemd --new --files --name <my-pod-name>

and get back DEPRECATED command: blablabla

..which to me, as an end user: "hey! you're doing something the old way which we will be retiring soon." -- when I get something like that I would expect there also to be a pretty concise and coherent message about what exactly I am supposed to be doing "the new way", which I am not just not groking from the discussion..

What exactly should I do to be running a container in podman via systemd in 2024 "the right/new way"?

EDIT: I don't understand or really care what a quadlet is, but if I am supposed to use them to make podman run something in systemd, how I make one?

[rhatdan]

There are a few blogs on using quadlet
https://www.redhat.com/sysadmin/quadlet-podman
https://www.redhat.com/sysadmin/multi-container-application-podman-quadlet
Then there is the man page

man quadlet

[rugk]

man quadlet

Totally underrated and as I read this… wow 🤯 😲
I did not understand this exists (it's written nowhere) and it's also not easily findable if you search (via tab) for something like podman-quadlet or other podman-* things (which already yields 217 results/commands – so this does not even seem to be all).

[rhatdan]

$ man -k quadlet
podman-systemd.unit (5) - systemd units using Podman Quadlet
quadlet (5) - systemd units using Podman Quadlet

Hint they are both the same document.

[rugk]

Don't know if it is a bug, but in Fedora SIlverblue that command does not work:

$ man -k quadlet         
quadlet: nothing appropriate.

While man quadlet e.g. works and podman-systemd.unit, too.

[rhatdan]

I think this means Silverblue is not populating the man page cache. mandb?

[janpfeil]

I still got no answer from the long discussion: How do I generate the systemd .service files from my existing compose.yml files?
Is there any bash script provided?

[janpfeil]

Found it: podlet compose

[stuartm]

My wasted afternoon - A user story:

Like most here, I was left scratching my head by a mysterious "you're doing it wrong dummy" message displayed when running podman generate systemd. What are Quadlets?

So down the rabbit hole I go. A search engine sends me to the official documentation which happily tells me how much easier Quadlets will make my life. I try curb my cynicism because maybe this time that claim is made it will actually be true? What follows in the documentation immediately makes a lie of that claim, for I'm told that instead of running a simple one-liner to generate a service file I now need to hand craft an intermediate configuration file that will then be used to generate that same service file. A sure fire win for abstraction and obfuscation.

< OK. Deep breath. Must not lose temper, be civil and courteous ... >

An example of this.container file is given, it looks simple and straightforward. Then again the example use case is about as basic and well useless as it gets. In digging deeper, much, much deeper it turns out that for a real world use case, with a real world container requiring networking, loading of external variables, local volume mounts and more this container file actually becomes a complete re-write of the compose.yaml in a brand new and different format with different syntax. By hand.

< Sigh >

This can't be right, they said this was better, that it was easier. Let's do some more research, what was this thing called again ... podlet? Sure let's search for podlet ... Oh, OK, not what I meant to search for, but brilliant find. It turns out there IS a way to generate these files from those existing standard compose.yaml and even a running container. Hang on, though, why isn't this standard?? Why isn't this the behaviour of podman generate systemd? Ahh, it's a third party effort - well, way to go k9withabone! Let me just run this -

podlet compose compose.yaml
-bash: podlet: command not found

Doh. Not installed, stupid me.

dnf install podlet
No match for argument: podlet
Error: Unable to find a match: podlet

< Long exasperated sigh >

Looks at time. Wasted 2 hours already to do what used to take 10 seconds. At this point I'll save you the odyssey of getting podlet installed except to say that container install wouldn't work due to mysterious permission issues, both methods of cargo install failed halfway through on F39 and finally got there another hour later using the binary download. Generated my container file, finally. Would have been faster by hand after all, but hindsight and at least this should be faster for all those other containers.

Install my .container file to /etc/containers/systemd/ as the documentation tells me to do. Run systemctl daemon-reload. Almost there ... enable the service and ... Failed to enable unit: Unit file foo.service does not exist..

< Scream >

Back to the documentation. There's a second location given, that must be the answer. Moved the container file there, reload, still no .service file generated.

< THUD Sound of head hitting desk >

Run podman generate systemd foo > /etc/systemd/system/foo.service; systemctl enable foo; systemctl start foo.

Realisation - later versions of podman may drop simple systemd functionality and significantly complicate my life. Solution:

dnf versionlock podman

Finally gets back to doing real work before boss asks why I've spent a whole afternoon on something that should have taken seconds. The End.

[vrothberg]

Thanks a lot for your time sharing your experience, @stuartm!

I am sorry you feel like having wasted 2 hours. At the moment, there are no plans to remove generate systemd as we know and appreciate that it's being widely used. The upcoming Podman 5.0 does not remove it. So there is no need to version lock Podman. "Deprecation" in this context means that we will not be adding new features but only address critical bugs. So you can continue using generate systemd.

I will carefully re-read your comment on Monday and reply to your questions. This is useful feedback and I hope we can improve the documentation and user experience.

[jafd]

"Deprecation" in this context means that we will not be adding new features but only address critical bugs.

Could you then please call it "feature-complete" or "done", which is Good™, meaning "we promise we won't be moving your cheese", and not "deprecated", which is Bad™, meaning "we are going to disappear it any day now"?

[zmc]

I've just found this discussion after seeing the deprecation notice on an F39 server, and attempting to research what I'm supposed to be doing instead. The podman-systemd.unit manpage referenced by the command doesn't make it clear how these Quadlet files should be written or generated. There's no quadlet or podman quadlet command, and apropos quadlet only shows the podman-systemd.unit manpage. dnf search quadlet yields no results.

The linked blog posts are a bit more helpful in that they show the file formats, but it looks like the new workflow is to hand-write a bunch of systemd files.

https://www.redhat.com/sysadmin/quadlet-podman:

The Quadlet-generated service file uses the same libraries as podman generate systemd –new but hides the complexity from the user.

I don't understand how complexity is being hidden here, or how; it would take me hours to properly write out the necessary files for my deployments.

It's good to hear that the original generate-systemd feature isn't going to be removed. I do wish the "deprecation" notice was a bit more honest, as that would have saved me considerable time.

[DaveWK]

+1 to the fact that making up a goofy marketing name of "quadlet" and telling everyone the way they are doing things is deprecated without any details is about as far from "removing complexity" as it gets.

on principle I kinda hate quadlet now while knowing very little about it.

Instead of renaming features to confusing buzzwords with documentation that looks like a protobuf spec, the documentation could have a srtraightforward example of how to reproduce generate systemd without all the "if you're doing something that involves a zillion niche edge cases, here's several paragraphs to obfuscate what should be a straightforward process"

[rhatdan]

PR's welcome to help the documentation.

[vrothberg]

What follows in the documentation immediately makes a lie of that claim, for I'm told that instead of running a simple one-liner to generate a service file I now need to hand craft an intermediate configuration file that will then be used to generate that same service file. A sure fire win for abstraction and obfuscation.

I don't think that using generate-systemd is a simple one-liner. The container needs to be created first, and then generate-systemd can generate service file based on that container. The service file must then be enabled/started.

Using Quadlet, a file must be written once is then automatically loaded. Quadlet is especially beneficial for day-2 operations. Let's assume there is a fix for the .service generator. With generate-systemd, the files must be recreated manually while it's fully transparent using Quadlet without any manual intervention.

In digging deeper, much, much deeper it turns out that for a real world use case, with a real world container requiring networking, loading of external variables, local volume mounts and more this container file actually becomes a complete re-write of the compose.yaml in a brand new and different format with different syntax. By hand.

That is a fair point. Migrating from Docker Compose to Quadlet requires work and there is no silver bullet.

This can't be right, they said this was better, that it was easier.

I do believe Quadlet is easier and better than generate-systemd once migrated. There is no trivial migration path though.

Let's do some more research, what was this thing called again ... podlet? [...] Hang on, though, why isn't this standard?? Why isn't this the behaviour of podman generate systemd?

podlet is a community project and not part of Podman. We want to discourage the old workflow of creating containers/pods first and then generating .service files. I understand that this requires manual work migrating off generate-systemd. That is why we do not want to remove generate-systemd and decided to keep it. No new features but urgent bug fixes.

Maybe we should add that to the deprecation notice when running generate-systemd?

Install my .container file to /etc/containers/systemd/ as the documentation tells me to do [...]

That depends whether you want to run the .service as root or not. /etc/containers/systemd is only accessible as root, /etc/containers/systemd/users/ and .../$(UID) is accessible for rootless users (plus the $HOME/.config dirs).

I believe we need to improve the docs to make the behavior clearer. That is very valuable feedback, thank you!

[amasolov]

Install my .container file to /etc/containers/systemd/ as the documentation tells me to do [...]

That depends whether you want to run the .service as root or not. /etc/containers/systemd is only accessible as root, /etc/containers/systemd/users/ and .../$(UID) is accessible for rootless users (plus the $HOME/.config dirs).

Adding a .container or a .service file to /etc/containers/systemd does't add anything to 'systemctl list-units' after doing 'systemctl daemon-reload'. I can relate to what was shared earlier by @jafd. It's a frustrating experience and a waste of time.

[ygalblum]

/etc/containers/systemd is a Quadlet input directory. So, adding .service files will not do anything.

As for the .container file, can you please verify the file with a dry run:
/usr/libexec/podman/quadlet -dryrun

[zastrixarundell]

Yeah. I don't like the current implementation of 'this is deprecated'.

I would most likely be fine with quadlets if there was an official built-in generator. (as someone pointed out, maybe quadlet will be deprecated in a few years, systemd won't).

• The documentation is too verbose. I'm not going to read a 20+ page file to start a simple minecraft container to play with friends.
• There's no built-in generator command. This is the simplest way to make people get started. Make a podman generate quadlet and I'll use it to learn quadlet. I'm not going to do so otherwise honestly.

As per other comments:

• I ran generate systemd.
• Tried to look into quadlet.
• Saw the verbose documentation without any simple examples at the top (I'm not going to read it all).
• Spent 30+ minutes trying to figure it out (I didn't).
• Saw this conversation.
• Saw podlet. sudo apt install podlet > not found
• Used podman generate systemd

Again. I understand quadlet is super good for automation of environments if it's baked into podman. But it's not a good idea to NOT provide a generator command. It's way easier for me to generate a container with one line and then just create a service file based off an existing container rather than to read some documentation somewhere and to figure it out fully.

[vrothberg]

I am (quite strictly) against adding a generate-quadlet command. There is already podlet maintained by the community and it works great. Adding it to Podman would mean a lot of duplicated work. Whenever a new feature is being added, it had to be added to multiple places at once.

I do not want to disqualify the desire of some folks to have such functionality but it is already there with podlet. If users want to use the old generate command, they can use it. As mentioned in the thread, deprecated means that it won't receive new features. But there are not plans to remove it.

[zastrixarundell]

@vrothberg that makes sense. I did read more into the readme for podlet and it looks good. Honestly at least for me this would be a non-issue if it were present in repositories (and with that update the warning message to reference podlet as a solution).

I really don't like getting randomly precompiled binaries via wget/curl because I know I won't update it after some time as I'll simply forget their existence.

[Rivers47]

Quadlet documentation is simply a list of key translations indicating what you need to write for each CLI argument. The main benefit is that it can generate a service for each user. I think quadlet is more of an enterprise tool for systems with many users each needing to start their own predefined service. Also the correct way (since immutable system is their focus now) is to run podlet in a container. In fact podlet isn't even shipped with fedora, let alone debian based systems. If you just want to use it as a home user, use the CLI and save it in a script file is more than enough. I don't use podman compose because usually you need to modify the docker compose anyway.

[ygalblum]

Please note that Quadlet is not shipped as a standalone solution, it is part of Podman and as such is installed along with it for quite some while.
As for usage (I know I'm biased, but), I prefer it over script files. For example, sometimes for development I need to run a redis server. So, I have a Quadlet file redis.container in ~/.config/containers/systemd:

Image=docker.io/redis/redis-stack:latest
PublishPort=6379:6379
PublishPort=8001:8001
ContainerName=redis

Then all I need to do to start or stop the service is to use systemctl:

# Start the service
systemctl--user start redis
# Stop the service
systemctl--user start redis

Without having to remember where is the script, what was its name, etc.

[jdoss]

I am (quite strictly) against adding a generate-quadlet command. There is already podlet maintained by the community and it works great. Adding it to Podman would mean a lot of duplicated work. Whenever a new feature is being added, it had to be added to multiple places at once.

I do not want to disqualify the desire of some folks to have such functionality but it is already there with podlet. If users want to use the old generate command, they can use it. As mentioned in the thread, deprecated means that it won't receive new features. But there are not plans to remove it.

@vrothberg I am glad that podlet exists (TBH I forgot about it and I have it starred on GH already) and I am going to use that to start converting my systemd units that I create with the podman systemd generate command.

That being said, I can understand from an ease of use standpoint the desire of users wanting to have the features of podlet added to Podman. The big problem is that new users to Podman and quadlets have to know that podlet is a thing. They don't have to remember that podlet is a thing and have to install yet another binary. Even us Podman veterans forget about all of the different third party tooling available.

When I am working on making a new pod with containers I often start with a bash script of podman run --replace ... commands so I can quickly iterate on the design of my pod + containers. Using the systemd generate features of Podman make it super easy to create unit files after I have everything in order so I can then transfer those units into my production automation. Just last week I was doing this exact workflow and I thought it would be super neat if I didn't have to RTFM for creating quadlet files to start using them. It is so easy to use podman systemd generate and I wished that there was a podman quadlet generate command to enable me to use quadlets instead.

I totally understand and respect your desire to not add duplicated work into podman with features that podlet provides, but I do think there is great value from a user experience POV with having a podman quadlet generate command built into Podman.

I have been watching this thread for over a year now and I think the big takeaway IMO from the discourse surrounding podman generate systemd is users really like this feature of podman. It makes their lives easier when running pods / containers via systemd and anything that can be added to make quadlets easier to use (such as podman quadlet generate) is something that should be heavily considered.

[DaveWK]

My original impression was podman was a runc/crun wrapper akin to docker's CLI, and that if I was doing k8s work I should be using the "cri-o" implementation, because podman was not the appropriate tool to be mashing into k8s, ergo shouldn't have all this k8s baggage since it's primary use case is not to be integrated with k8s, and cri-o would "go a level down" and just leverage crun/runc/docker and podman was just a "doable hack" that added more unnecessary overhead.. I guess I don't see the point in getting in a tizzy about shoehorning k8s features into podman and making it less user friendly.

[rhatdan]

The "Shoehorning" of k8s YAML into Podman is more of using a common language for defining complex applications involving multiple containers. Rather then using a deadend language like Compose where it only works on docker or Podman, we think it makes more sense to use k8s YAML for workloads on edge or in a k8s cluster.

[DaveWK]

I was under the impression podman was not intended to be a replacement for cri-o, and intentionally has niceties that are geared towards a dev/user-friendly/debugging experience locally and most importantly without the obnoxiousness of all the k8s boilerplate of defining defaults for edge cases most people will never need that are required in a multi-node "full" k8s cluster but not required in a single-instance dev environment (and of course without the horrible parent docker daemon service). While "Compose" may have fallen out of fashion I don't enjoy the infliction of kuber-nonsense syntax when I am trying to run a singleton in systemd, and would rather just have a trimmed down feature set locally and "bite the bullet" with cri-o than keep moving those goalposts.

[rhatdan]

Your assumption is Wrong. Podman and CRI-O need to co-exists. CRI-O is a dedicated container engine for running kubernetes workloads, supporting everything kubernetes needs.
Podman and a single purpose single node container engine which while it support k8s yaml, it does not work with kubelet and support most other k8s features, and has no intention too.

Podman while not a daemon requires systemd to manage its containerized services. Quadlet is a tool to make this happen.

There is not requirement to use k8s.yaml for defining complex applications, it is just an added benefit that Podman supports it.

Quadlet can run containers, pods and manage volumes, networks, images and builds all without k8s.

Podman can also run pods and containers via CLI.

Podman service supports compose functionality at the API level.

There are two implementations of compose docker-compose and podman-compose (Which is a separate project then Podman, and not worked on by the Podman maintainers). Podman can work with both docker-compose of podman-compose.