search

containers / podman

Podman: A tool for managing OCI containers and pods.
https://podman.io
Apache License 2.0
23.71k stars 2.41k forks source link

Mismatch between quadlet options and kube play options? #18661

Closed void-spark closed 1 year ago

void-spark commented 1 year ago

Feature request description

Actually more of a question than a real request.

I noticed that podman play kube supports more options on the commandline, than can be provided using a 'kube' unit with quadlet, I think... A example that stands out in my case is '--ip', but also '--log-driver' if I'm not mistaken. I think there are several more? I wonder if this is intentional, unfinished, or accidental, or am I just missing something? :) I can see this being a intentional design choice, I don't have enough overview yet to understand that. Or maybe I've missed something in the manual :)

Suggest potential solution

If this is not by design, additional options could be added to the 'kube' unit file for all missing arguments that play kube supports. Or if kube play moves quicker than quadlet, it's possible to add a 'ExtraArgs' option or such which gets passed directly to kube

Have you considered any alternatives?

A workaround is to just copy the generated systemd unit file, and manually modify that. You don't use quadlet anymore then, but I don't think that makes much difference at the moment?

Additional context

No response

Luap99 commented 1 year ago

I would not recommend using --ip, you can set the ip via the network options: --network name:ip=.... this is important when you use more then one network which will not work when using --ip.

Regardless IP= is supported in the container unit so there shouldn't be a reason to not add it to the kube unit as well. Also there is already a PodmanArgs= key in the container unit to set arbitrary args, I guess we should support the same for kube?

cc @vrothberg @ygalblum

ygalblum commented 1 year ago

Some entries were not implemented initially because Quadlet started off more opinionated that it currently is. Now that it is un-opinionated, I don't think there is any formal reason not to implement the support of any of the keys.

Having said that, we do not wish to mandate that each and every argument be supported (to avoid release issues). So, users are more than welcomed to open PRs adding new keys. Please note that the support for LogDriver was already added to the code base.

One thing though, I think we should add the support for the PodmanArgs= key to the Kube section to provide a workaround for any missing key.

ygalblum commented 1 year ago

I've opened #18670 to address the missing PodmanArgs key in .kube, .network and .volume files.

Should I add that it resolves this issue, or is there anything else we want to address for this one?

void-spark commented 1 year ago

For me (OP :)) I have all my answers at least, I didn't realize instead of --ip I could use --network, so the Network key in quadlet-kube, that helps! And knowing LogDriver will be in the next version is helpful, also I'm figuring out if the current hard default from quadlet 'passthrough' would be a acceptable/better option for us, right now we use journald, I kinda get what passthrough does now, it literally passes through to the calling process, which is systemd, so that systemd now handles the logs. On 4.4.1-rhel (the one we use now, it would have been nice if it actually shows that in the version instead of 4.4.1 :) ) it will break podman log commands, but I think we're ok with just journalctl. Just figuring out which -u or -t options to use with it to get the different logs, and how/if that is different from using journald :)

ygalblum commented 1 year ago

Following @void-spark's comment and the merge of #18670, I'm closing this issue.

Luap99 commented 1 year ago

it will break podman log commands, but I think we're ok with just journalctl.

It will work with v4.5+ (https://github.com/containers/podman/pull/17502)