unable to find mount source when generating kube yaml being rootless

[Fodoj]

/kind bug

Version

Podman 1.3.0-dev

OS

Fedora Workstation 29, Linux linux.fritz.box 5.0.4-200.fc29.x86_64 #1 SMP Mon Mar 25 02:27:33 UTC 2019 x86_64 x86_64 x86_64 GNU/Linux

How to reproduce

Note that probably not all ports are needed or even matter. But I still provide full commands I executed:

podman pod create --name mkdev-dev -p 5432 -p 8000 -p 3000 -p 6379
podman run -e POSTGRES_PASSWORD=secrets -v $(pwd)/tmp:/var/run/postgresql:z --pod mkdev-dev postgres:9.6.9 
podman generate kube mkdev-dev
# => Error: unable to find mount source

[Fodoj]

Aftrer digging into source code, it looks like the source and destination of volume mounts is mixed in kube.go. I could fix it by doing this:

@@ -342,8 +340,8 @@ func libpodMountsToKubeVolumeMounts(c *Container) ([]v1.VolumeMount, error) {
        // At this point, I dont think we can distinguish between the default
        // volume mounts and user added ones.  For now, we pass them all.
        var vms []v1.VolumeMount
-       for _, hostSourcePath := range c.config.UserVolumes {
-               vm, err := generateKubeVolumeMount(hostSourcePath, c.config.Spec.Mounts)
+       for _, mount := range c.config.Spec.Mounts {
+               vm, err := generateKubeVolumeMount(mount.Source, c.config.Spec.Mounts)
                if err != nil {
                        return vms, err
                }

But then I receive another error: Error: volume names: not yet implemented.

/cc @baude according to git history you worked on kube.go most?

[rhatdan]

@haircommander PTAL

[kofalt]

I was able to reproduce this using only commands from the RH blog about pod / kube interop:

$ podman run --pod new:demodb -P -e MYSQL_ROOT_PASSWORD=x -dt quay.io/baude/demodb:latest

$ podman pod ls
POD ID         NAME     STATUS    CREATED              # OF CONTAINERS   INFRA ID
389f5ece4a83   demodb   Running   About a minute ago   2                 6326337508e3

$ podman generate kube demodb
Error: unable to find mount source

This was on 1.3.1-dev and is a pretty simple setup.
Does anyone know if there's a way to work around this? It'd be a cool feature :)

[mheon]

I think this would be my rework of named volumes in 1.3 - one or more of those containers probably has an image volume, and it seems I missed this bit of code when I migrated image volumes out of the Libpod spec.

For now, it's probably sufficient to take https://github.com/containers/libpod/blob/master/libpod/kube.go#L337 and make it not return an error (or silently discard said error) - Libpod named volumes aren't really Kube hostpath volumes, and we haven't convinced play kube to play nicely with our named volumes yet either.

[kofalt]

On podman 1.4.0 my above example from the RH blog works 🎉

Note that podman play kube on the result will still fail until #3157 is fixed.
@Fodoj maybe give it another shot? I think this can be closed.

$ podman version
Version:            1.4.0
RemoteAPI Version:  1
Go Version:         go1.10.4
OS/Arch:            linux/amd64

[haircommander]

Given #3157 is fixed, and the above reproducer works for me on 1.4.3, I'm closing this. Feel free to reopen if you disagree @Fodoj !