Bug 1765476

This is not a bug.  The image is required for pods by design.

Why not just create a image tar ball that we ship under /usr/share/containers and then we can just pull this in to the tool if it does not exists?

I think this is a bug, disconnected systems are definitely something we want to support.

this is the same issue that would be encountered with an offline CRI-O installation.

I think we need to document the issue and let people use a different `pause_image=` in `/etc/containers/libpod.conf`.

Another alternative would be to create the pod with `--infra=no`

What do you think about just having the image in a tar ball and we load it from their rather then pulling it from the internet?

carrying an additional binary blob that will be used in very rare cases seem costly and error prone.

We could probably fall back to creating a container using the first image available in the storage and setting the command to "tail -f /dev/null".

What do you think?

That would require a container containing tail.  We could also just include the pause executable, and build a container on the fly.
from scratch
copy pause /pause
entrypoint /pause

where do we get /pause?  I am fine with adding a new pause executable to podman, that would also be useful/used with rootless containers instead of re-execing Podman.

https://github.com/kubernetes/kubernetes/blob/master/build/pause/pause.c

(In reply to Giuseppe Scrivano from comment #5)
> this is the same issue that would be encountered with an offline CRI-O
> installation.
> 
> I think we need to document the issue and let people use a different
> `pause_image=` in `/etc/containers/libpod.conf`.
> 
> Another alternative would be to create the pod with `--infra=no`

I am supportive of Giuseppe's proposal. Disconnected deployments need to get the images in any case from somewhere. The pause image would just be one of many.

Documenting this scenario, adding a `pause_image` and being aligned with CRI-O seems worth approaching to me.

# Default infra (pause) image name for pod infra containers
infra_image = "k8s.gcr.io/pause:3.1"

# Default command to run the infra container
infra_command = "/pause"

Present in the default libpod.conf today. More visibility in the docs could be good, but from a config standpoint, we're completely set.

Valentin, isn't this something where we could take advantage of mirroring? also?

(In reply to Daniel Walsh from comment #13)
> Valentin, isn't this something where we could take advantage of mirroring?
> also?

I'm not sure mirroring would help here, unless a user wants to specify an air-gapped mirror for "k8s.gcr.io".

As Matt mentions above, libpod.conf already supports setting the infra image and its command, so I don't think there is much left we can do besides improving documentation.

Note that it's possible to let the `infra_image` point to a local image (e.g., "oci:/home/valentin/infra").

There are two possible workarounds:

1) if they are using an internal registry, they can use skopeo to copy the pause image there:

$ skopeo copy docker://k8s.gcr.io/pause:3.1 docker://internal.registry/pause:3.1

Then change the infra_image setting in /etc/containers/libpod.conf to point to the new location:

#infra_image = "k8s.gcr.io/pause:3.1"
infra_image = "internal.registry/pause:3.1"


2) it is possible to create the image locally (the first method is better though), using tail.

Create and launch this script:

-------------------------------------------
#!/bin/sh

IMAGE=fedora

printf "#!/bin/sh\ntail -f /dev/null" > pause
chmod +x pause
cat > Dockerfile <<EOF
FROM $IMAGE
COPY pause /pause
ENTRYPOINT /pause
EOF

podman build -t infra-pause .
-------------------------------------------

You still need to have a base image, please update IMAGE= accordingly in the script.  I've used fedora for my test.

Once that is done, you still need to update infra_image in the /etc/containers/libpod.conf file:

#infra_image = "k8s.gcr.io/pause:3.1"
infra_image = "infra-image"



The same method applies for rootless containers: just make sure to use ~/.config/containers/libpod.conf instead of /etc/containers/libpod.conf

I have a feeling this is more about getting two containers to talk to each other.  Podman 1.6.4  or Podman 1.7 has dns support to make this happen, I believe.

You need to change containers.conf now, libpod.conf is no longer supported.

Is this just a documentation issue?

Matt, Giuseppe any update on this one?

I believe the suggested workarounds require Bug 1853455 to be fixed first

Fixes will be in podman 3.0 to make the workaround possible.

Perhaps here from containers/common

```
common (format) $ git show 7f460be90af569956699d003fbd47fd4cd44e23b
commit 7f460be90af569956699d003fbd47fd4cd44e23b
Author: Matthew Heon <mheon>
Date:   Thu Nov 19 15:43:36 2020 -0500

    We should not be setting a default infra command.
    
    We should be sourcing from the image CMD/ENTRYPOINT by default.
    Having a default prevents us from doing that - we should only be
    using this for user-configured values that do not come from the
    image.
    
    Signed-off-by: Matthew Heon <mheon>

diff --git a/pkg/config/default.go b/pkg/config/default.go
index 5f8f499..29eb3c3 100644
--- a/pkg/config/default.go
+++ b/pkg/config/default.go
@@ -46,8 +46,6 @@ var (
        DefaultInitPath = "/usr/libexec/podman/catatonit"
        // DefaultInfraImage to use for infra container
        DefaultInfraImage = "k8s.gcr.io/pause:3.2"
-       // DefaultInfraCommand to be run in an infra container
-       DefaultInfraCommand = "/pause"
        // DefaultRootlessSHMLockPath is the default path for rootless SHM locks
        DefaultRootlessSHMLockPath = "/libpod_rootless_lock"
        // DefaultDetachKeys is the default keys sequence for detaching a
@@ -308,7 +306,6 @@ func defaultConfigFromMemory() (*EngineConfig, error) {
        c.InitPath = DefaultInitPath
        c.NoPivotRoot = false
 
-       c.InfraCommand = DefaultInfraCommand
        c.InfraImage = DefaultInfraImage
        c.EnablePortReservation = true
        c.NumLocks = 2048
```

99% sure that is completely separate. Was the fix here not that we now build the pause image ourselves?

If the request is that we should not require a non-local pause image at all, this is not resolved.

Development Management has reviewed and declined this request. You may appeal this decision by reopening this request.

Ok well we have suggested fixes for it, so I am going to close.

Suggested fix accepted.