remote build: document that only the docker and containers-storage transport work

[graywolf-at-work]

Is this a BUG REPORT or FEATURE REQUEST? (leave only one on its own line)

/kind bug

Description

When trying to build from local oci-archive, the build does not work on macos.
Works fine on linux.

Steps to reproduce the issue:

$ skopeo --override-os=linux copy docker://alpine:3.16 oci-archive:alpine.tar && echo 'from oci-archive:alpine.tar' >Containerfile && podman build .
Getting image source signatures
Copying blob 530afca65e2e done  
Copying config b72857f16e done  
Writing manifest to image destination
Storing signatures
STEP 1/1: FROM oci-archive:alpine.tar
Error: error creating build container: creating temp directory: open /var/home/core/alpine.tar: no such file or directory

Describe the results you received:

STEP 1/1: FROM oci-archive:alpine.tar
Error: error creating build container: creating temp directory: open /var/home/core/alpine.tar: no such file or directory

Describe the results you expected:

STEP 1/1: FROM oci-archive:alpine.tar
Getting image source signatures
Copying blob 530afca65e2e skipped: already exists  
Copying config b72857f16e done  
Writing manifest to image destination
Storing signatures
COMMIT
--> b72857f16e6
b72857f16e642ea7fbb8d6febebd00278f366fbf2d15294d784b8edd473dbde0

Additional information you deem important (e.g. issue happens only occasionally):

Output of podman version:

Client:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.18.3
Built:        Tue Jun 14 22:12:46 2022
OS/Arch:      darwin/amd64

Server:       Podman Engine
Version:      4.1.1
API Version:  4.1.1
Go Version:   go1.18.3
Built:        Wed Jun 22 18:17:44 2022
OS/Arch:      linux/amd64

Additional environment details (AWS, VirtualBox, physical, etc.):

amd64-base mac book pro

[mheon]

@flouthoc PTAL

[vrothberg]

I am not sure that is something we can easily/realistically support for remote clients. It would work if the archive is on the server side (i.e., the Linux VM) but it does not work when the archive is on the client side (i.e., MacOS).

I think that's probably something we need to document.

Cc: @nalind @rhatdan

[rhatdan]

Does this work in Docker? We are supposed to be copying over the context directory to the server side and using it. Which to me means the archive should have been copied over, and we are just not getting the right path. Wouldn't this be a bug in Podman and not in buildah.

[vrothberg]

Does this work in Docker?

No. Docker only supports images on a registry or in the local storage.

We are supposed to be copying over the context directory to the server side and using it. Which to me means the archive should have been copied over, and we are just not getting the right path. Wouldn't this be a bug in Podman and not in buildah.

We are copying over the build context but this is a reference in a Dockerfile to a non-Docker transport. Podman had to preprocess the Dockerfile, and copy these archives outside the build context on the server.

IMHO, referencing files outside the build context is something for Podman on Linux. Hence the suggestion to document that non-Docker and non-storage references are not supported for remote clients.

[rhatdan]

I am not sure why Podman is parsing the Containerfile on the client side. Give me a dope slap on the question on Docker support, :^(. Anyways since this does not work in Docker, I am fine with documenting it is only supported via podman --remote=false build.

[vrothberg]

I am not sure why Podman is parsing the Containerfile on the client side.

It does not but it had to if we wanted to support the scenario.

Let's consider the following file:

FROM oci-archive:/tmp/on/the/client/archive.tar

Currently, the build fails for a remote client because the path relates to the client machine. Making that work seems extremely tedious and error prone to me, so I don't think we should support it (given Docker does not).

[rhatdan]

@graywolf-at-work interested in opening a PR on the man page to document this on podman build?

[Luap99]

If the oci archive is already part of the build context like it is the case here we should be able to use it on the remote server. The problem is that the cwd is different on the server, we would need to lookup the path relative to the build context and not the cwd.

[rhatdan]

Yup, but as @vrothberg points out you can specify a full path in the from command that would not be understood by the remote build or the builder. Theoretically we could make this work, but I don't think it is worth it.

[graywolf-at-work]

I can send a PR, however now that I look I'm not sure where the support for from oci-archive:... is documented. I admit I've "discovered" it by accident, so not sure against what documentation to make the PR.

[rhatdan]

It should be against podman build indicating that in remote mode only the "docker" transport is supported.

[vrothberg]

It should be against podman build indicating that in remote mode only the "docker" transport is supported.

And "containers-storage" (see man containers-transports).