pkg/kube/quadlet: add podman kube quadlet subcommand

[asafbennatan]

this is useful for converting pod.yaml into first class systemd (quadlet) units .
the current kube play approach bypasses native qudlet constructs making it harder to manage.

the approach taken by podman kube play is understandable since it precedes quadlets .
i suspect that if this was done today - translating it to quadlets would have been the approach taken

[packit-as-a-service]

[NON-BLOCKING] Packit jobs failed. @containers/packit-build please check. Everyone else, feel free to ignore.

[Luap99]

Why would this be needed when we have kube unit support already that just run directly from the yaml?

This is a lot of code for something that is already possible to do AFAICT.

[Luap99]

what does this actually do, why would this be needed, commands are contained in the image and a script should not be extracted anywhere and then bind mounted again.

[asafbennatan]

this handles the case where you have :

initContainers:
- name: init-disk-rootdisk
  command: ["/bin/bash", "-c", "cp /disk/disk.img /var/run/.../rootdisk && chmod ..."]

in this case you do not have an image

and escaping gets complicated , thats why its extracted to a separate file

[Luap99]

That is a poor excuse, having sperate files that need to manage din addition of this makes this much more complicated. Anyhow lets not focus on the details when the main question do we need this.

[asafbennatan]

ill be happy to adjust per your comments but as you said lets first establish this is aligned with the project's goals

[Luap99]

also note https://github.com/podman-container-tools/podman/blob/main/LLM_POLICY.md

[asafbennatan]

Why would this be needed when we have kube unit support already that just run directly from the yaml?

This is a lot of code for something that is already possible to do AFAICT.

podman kube play was created back in 2019 as far as i know , quadlets were added to podman at 2023 as far as i know .
the timeliness difference explains why this translation never happened though quadlets which is the preferred approach for controlling services on RHEL.

[asafbennatan]

also note https://github.com/podman-container-tools/podman/blob/main/LLM_POLICY.md

apologies - fixed commit and PR messages

[Luap99]

Why would this be needed when we have kube unit support already that just run directly from the yaml?
This is a lot of code for something that is already possible to do AFAICT.

podman kube play was created back in 2019 as far as i know , quadlets were added to podman at 2023 as far as i know . the timeliness difference explains why this translation never happened though quadlets which is the preferred approach for controlling services on RHEL.

That does not answer my question.

We do have kube units https://docs.podman.io/en/latest/markdown/podman-kube.unit.5.html, just put a single quadlet and kube file and there you go. No need to translate anything here.

This here adds basically a completely new kube parser to all out existing kube logic which adds unnecessary duplication and makes maintance much harder long term which is why I am opposed to doing this when this is already possible.

[asafbennatan]

Why would this be needed when we have kube unit support already that just run directly from the yaml?
This is a lot of code for something that is already possible to do AFAICT.

podman kube play was created back in 2019 as far as i know , quadlets were added to podman at 2023 as far as i know . the timeliness difference explains why this translation never happened though quadlets which is the preferred approach for controlling services on RHEL.

That does not answer my question.

We do have kube units https://docs.podman.io/en/latest/markdown/podman-kube.unit.5.html, just put a single quadlet and kube file and there you go. No need to translate anything here.

This here adds basically a completely new kube parser to all out existing kube logic which adds unnecessary duplication and makes maintance much harder long term which is why I am opposed to doing this when this is already possible.

kube.unit is a shim for pod.yaml it does not express native quadlet hierarchy of networks , pods , containers etc

[mheon]

I don't mind the concept of this at all - I'm personally very in favor of a Compose YAML to Quadlet compiler, and this is next door to that, conceptually. I do wonder if Podman is the right place, though. https://github.com/containers/podlet is where the existing state-of-the-art in Compose-to-Quadlet lives, and maybe this should be in there as well?

Alternatively, we could say that both compilers should be in Podman, merge this, develop our own Compose compiler - there are definitely benefits to that, keeping everything in one tool, but it's also a duplication of effort that I'd prefer to avoid...

[mheon]

(In short, I definitely like this idea, just not sure where the best place to put it is)

[asafbennatan]

I don't mind the concept of this at all - I'm personally very in favor of a Compose YAML to Quadlet compiler, and this is next door to that, conceptually. I do wonder if Podman is the right place, though. https://github.com/containers/podlet is where the existing state-of-the-art in Compose-to-Quadlet lives, and maybe this should be in there as well?

Alternatively, we could say that both compilers should be in Podman, merge this, develop our own Compose compiler - there are definitely benefits to that, keeping everything in one tool, but it's also a duplication of effort that I'd prefer to avoid...

is this related to podman in any way or community driven ?
i can try adding it there if this is what feels right

[Luap99]

I don't mind the concept of this at all - I'm personally very in favor of a Compose YAML to Quadlet compiler, and this is next door to that, conceptually. I do wonder if Podman is the right place, though. https://github.com/containers/podlet is where the existing state-of-the-art in Compose-to-Quadlet lives, and maybe this should be in there as well?
Alternatively, we could say that both compilers should be in Podman, merge this, develop our own Compose compiler - there are definitely benefits to that, keeping everything in one tool, but it's also a duplication of effort that I'd prefer to avoid...

is this related to podman in any way or community driven ? i can try adding it there if this is what feels right

Personally I would have rather hard objection dragging in the entire compose spec into podman directly.
This here is seems to be more something I can comprise on since the we do already have the kube file support in the codebase.

As for adding this into podlet I agree this would sounds like a great idea if they are willing to accept this, podlet is not maintained by us so you would need to confirm this with their maintainers first if that is even wanted to them.
I think source to source translations have no need to be in podman proper, if it does not need db access then doing this externally would help us I believe.
We have so many features already that I think we need to more carefully choose what we want in podman directly vs what can be solved externally.