search

containers / podman

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

kubernetes support doc does not list unsupported kinds #17054

Closed vrothberg closed 1 year ago

vrothberg commented 1 year ago

The Kubernetes support doc (and hence the man page) does not list unsupported kinds (e.g., services, jobs, etc.). To make it more useful and accurate, unsupported kinds should be mentioned as well.

Cc: @umohnani8 @benoitf @ashley-cui @rhatdan

vrothberg commented 1 year ago

Tagged as podman-desktop since we found the issue in the K8s working group.

rhatdan commented 1 year ago

We need to start supporting jobs.

vrothberg commented 1 year ago

We need to start supporting jobs.

Please open an issue :)

vrothberg commented 1 year ago

Kind "secret" isn't mentioned in this doc (Cc: @ashley-cui)

github-actions[bot] commented 1 year ago

A friendly reminder that this issue had no activity for 30 days.

rhatdan commented 1 year ago

Didn't @ygalblum or someone add secret support?

ygalblum commented 1 year ago

It was already supported before I started looking at it, but it had some issues that were resolved here #16631.

danishprakash commented 1 year ago

Adding Jobs support, is that something I can pick up If it's okay?

vrothberg commented 1 year ago

Didn't @ygalblum or someone add secret support?

Yes, secrets are supported but not mentioned.

vrothberg commented 1 year ago

Adding Jobs support, is that something I can pick up If it's okay?

Thanks! Sure, but let's discuss before how to best implement a job. @ygalblum, can you share your recent findings on jobs? What was your conclusion? My memory is fading, apologies.

ygalblum commented 1 year ago

NP. At first we started looking at Jobs as an alternative to Deployments when using Systemd since Jobs do not allow setting the restartPolicy to always. But, then we agreed (or at least I argued) that doing so is more an abuse of a feature than an actual solution and moreover, it will require users to keep two YAML files - Deployment and Job - which defies the purpose. As a result, we did not push forward the support for Jobs as part of Quadlet. Having said that, I think supporting Jobs will be a great addition to kube play. AFAIK there are two main differences. First, as I wrote before, restartPolicy cannot be set to always. Second, Jobs receive restart and success counts. Now, in order to support the second part, I think we will need to resolve the issue of failure propagation from the service container.

vrothberg commented 1 year ago

Thanks, @ygalblum !

Now, in order to support the second part, I think we will need to resolve the issue of failure propagation from the service container.

I think it can work without. If a container ran out of retries, it may just kill the service container which in turn would stop all containers/pods.

danishprakash commented 1 year ago

At first we started looking at Jobs as an alternative to Deployments when using Systemd since Jobs do not allow setting the restartPolicy to always. But, then we agreed (or at least I argued) that doing so is more an abuse of a feature than an actual solution and moreover, it will require users to keep two YAML files - Deployment and Job

I'm a little out of the loop here but why were Jobs considered as an alternative to Deployments in the first place? Also, I guess handling retry in Jobs should be trivial here.

Second, Jobs receive restart and success counts.

This is so that we when the user does a status, they can see what all jobs failed and otherwise?

github-actions[bot] commented 1 year ago

A friendly reminder that this issue had no activity for 30 days.

ygalblum commented 1 year ago

I'm a little out of the loop here but why were Jobs considered as an alternative to Deployments in the first place? Also, I guess handling retry in Jobs should be trivial here.

The idea was that systemd handles restarts better than podman as it can do exponential backoff, restart count, etc. But, when using Deployments, whose default restartPolicy is always, podman handles the restart without letting systemd know about it. Jobs, on the other hand, force the user to change the restartPolicy to either onFailure or never. Our recommendation would have been to use never when using systemd to allow the latter to handle the restart.

This is so that we when the user does a status, they can see what all jobs failed and otherwise?

This is about supporting Jobs regardless to systemd. By definition, jobs have a restart count (for when the restartPolicy is set to onFailure). So, if the container failed the restartCount amount of times, the Job's status is failed.

danishprakash commented 1 year ago

Our recommendation would have been to use never when using systemd to allow the latter to handle the restart. ...podman handles the restart without letting systemd know about it.

I might not have the complete context but are we somehow delegating container lifecycle related tasks over to systemd? If yes, have we been using it so far with other K8s resources? Put another way, why/when would podman let systemd know about certain kube container lifecycles?

This is about supporting Jobs regardless to systemd. By definition, jobs have a restart count (for when the restartPolicy is set to onFailure). So, if the container failed the restartCount amount of times, the Job's status is failed.

Makes sense, it's in line with k8s. I think I can start looking into it.

vrothberg commented 1 year ago

I think we can close this issue. I forgot what the motivating issue was to explicitly list unsupported fields of K8s YAML.