Play kube support for volumes created with podman volume create

[frezbo]

Play kube support for volumes created with podman volume create

/kind feature

Description
Play kube support for volumes created with podman volume create

[rhatdan]

This currently does not work? What happens?
@kunalkushwaha @sujil02 PTAL

[mheon]

We have support for bind-mount (and I think tmpfs) volumes, but not named volumes. Those generate additional bits of Kubernetes YAML, which we have to deal with in both generate kube and play kube (and there was some debate as to exactly what YAML was required). Probably not particularly difficult, but someone more familiar with Kube would be a good fit for this.

[kunalkushwaha]

I can look into this.

[github-actions]

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

[rhatdan]

@kunalkushwaha Any progress on this?

[rhatdan]

@mheon @haircommander Any ideas on this?

[mheon]

On our end, the real difficulty is figuring out the format for Kube volume YAML. Once we have that, I think it's a pretty simple mapping.

[haircommander]

named volumes sound like emptyDir. am I correct in saying so?

[mheon]

Hmm. That does sound pretty close. I'll take a look.

[frezbo]

@haircommander That seems fine to me too, since podman runs on the host.

[rhatdan]

@ryanchpowell Could you work with @haircommander on this?

[rhatdan]

@mheon @ashley-cui Could you take a look?

[xordspar0]

The problem with emptyDir is that its lifetime is the same as the pod. When the pod is created, a new empty volume is created. When the pod is destroyed, the volume is deleted forever. emptyDir is a scratch space for running applications. It's similar to /tmp, and it can optionally be memory-backed, similar to /tmp.

podman volumes are independent of pods; they can be created and destroyed on their own. This is more similar to Kubernetes PersistentVolumeClaims, which is an API designed for abstracting over vendor-specific storage like S3 or Google Cloud Storage.

[aodhan-domhnaill]

I opened a PR to support this. I am trying to figure out how to write unit tests for this. Any guidance would be appreciated. I'm a bit stuck trying to figure out how to mock the Runtime.

[AlbanBedel]

Using named volume in kube files is already possible, just use a hostPath volume with pathset to the volume name. This is working just fine for me:

  volumes:
    - name: app-data
      hostPath:
        path: my-named-volume
        type: Directory

[mheon]

If that works, I'd consider it more of a bug than a feature... I'm not saying we'll fix it, but if it breaks, fixing it will not be a priority.

[mheon]

#8497 merged and added support for persistent volume claims (backed by named volumes) to play kube. We do not, however, have support for this in generate kube yet, so I'll leave this open until that can be added.

[frezbo]

@mheon I can we can close this issue now. Kudos for implementing the fixes 👍 ❤️ Sorry for not being around.

[rhatdan]

@frezbo We still don't have generate kube according to @mheon .

[github-actions]

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

[rhatdan]

@mheon this is probably something you need to do.

[mheon]

Unassigning myself, I don't think I'm going to have time for this any time soon. Hopefully the New First Issue label will attract contributors?

[github-actions]

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

[rhatdan]

@umohnani8 PTAL

[jwillikers]

I just a came across a situation where having the generate behavior would be helpful.
I should be able to add this functionality later this week.

[xordspar0]

This has been on my to do list for a long time, and it just worked its way up to the top. @jwillikers, please go ahead and work on this, it would save me some work! But I'll probably get to it next week if no one is working on it at that time.