Open likan999 opened 10 months ago
@likan999 The command which you have pasted in description, does it produces build without layers or is it only happening when vscode
is trying to reach podman ?
@flouthoc thanks for your quick response. I've attached the log file when I tried to re-run the command on remote server (but with --log-level=trace
in case it helps). It looks like all previous steps are hit in the cache, but started to not use the cache for this command
[2/2] STEP 9/13: RUN --mount=type=bind,from=dev_containers_feature_content_source,source=node_0,target=/tmp/build-features-src/node_0 cp -ar /tmp/build-features-src/node_0 /tmp/dev-container-features && chmod -R 0755 /tmp/dev-container-features/node_0 && cd /tmp/dev-container-features/node_0 && chmod +x ./devcontainer-features-install.sh && ./devcontainer-features-install.sh && rm -rf /tmp/dev-container-features/node_0
On OSX Docker Desktop the same RUN
command is cached.
A friendly reminder that this issue had no activity for 30 days.
Can confirm that the same line is never cached for me.
### podman version
Client: Podman Engine
Version: 4.8.3
API Version: 4.8.3
Go Version: go1.20.12
Built: Wed Jan 3 14:11:31 2024
OS/Arch: linux/amd64
### /etc/*release
Fedora release 38 (Thirty Eight)
NAME="Fedora Linux"
VERSION="38.20240124.0 (Silverblue)"
ID=fedora
VERSION_ID=38
VERSION_CODENAME=""
PLATFORM_ID="platform:f38"
PRETTY_NAME="Fedora Linux 38.20240124.0 (Silverblue)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:38"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://silverblue.fedoraproject.org"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-silverblue/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://github.com/fedora-silverblue/issue-tracker/issues"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=38
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=38
SUPPORT_END=2024-05-14
VARIANT="Silverblue"
VARIANT_ID=silverblue
OSTREE_VERSION='38.20240124.0'
Fedora release 38 (Thirty Eight)
Fedora release 38 (Thirty Eight)
I wonder if #5445 helps with this.
The feature layer is still built from scratch.
### /etc/*release
Fedora release 40 (Forty)
NAME="Fedora Linux"
VERSION="40.20240614.0 (Sway Atomic)"
ID=fedora
VERSION_ID=40
VERSION_CODENAME=""
PLATFORM_ID="platform:f40"
PRETTY_NAME="Fedora Linux 40.20240614.0 (Sway Atomic)"
ANSI_COLOR="0;38;2;60;110;180"
LOGO=fedora-logo-icon
CPE_NAME="cpe:/o:fedoraproject:fedora:40"
DEFAULT_HOSTNAME="fedora"
HOME_URL="https://fedoraproject.org/atomic-desktops/sway/"
DOCUMENTATION_URL="https://docs.fedoraproject.org/en-US/fedora-sericea/"
SUPPORT_URL="https://ask.fedoraproject.org/"
BUG_REPORT_URL="https://gitlab.com/fedora/sigs/sway/SIG/-/issues"
REDHAT_BUGZILLA_PRODUCT="Fedora"
REDHAT_BUGZILLA_PRODUCT_VERSION=40
REDHAT_SUPPORT_PRODUCT="Fedora"
REDHAT_SUPPORT_PRODUCT_VERSION=40
SUPPORT_END=2025-05-13
VARIANT="Sway Atomic"
VARIANT_ID=sway-atomic
OSTREE_VERSION='40.20240614.0'
Fedora release 40 (Forty)
Fedora release 40 (Forty)
### podman version
Client: Podman Engine
Version: 5.1.0
API Version: 5.1.0
Go Version: go1.22.3
Built: Wed May 29 08:00:00 2024
OS/Arch: linux/amd64
### podman info
host:
arch: amd64
buildahVersion: 1.36.0
cgroupControllers:
- memory
- pids
cgroupManager: systemd
cgroupVersion: v2
conmon:
package: conmon-2.1.10-1.fc40.x86_64
path: /usr/bin/conmon
version: 'conmon version 2.1.10, commit: '
cpuUtilization:
idlePercent: 97.55
systemPercent: 0.85
userPercent: 1.6
cpus: 16
databaseBackend: sqlite
distribution:
distribution: fedora
variant: sway-atomic
version: "40"
eventLogger: journald
freeLocks: 2046
hostname: fedora
idMappings:
gidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 524288
size: 65536
uidmap:
- container_id: 0
host_id: 1000
size: 1
- container_id: 1
host_id: 524288
size: 65536
kernel: 6.8.11-300.fc40.x86_64
linkmode: dynamic
logDriver: journald
memFree: 2070827008
memTotal: 16471666688
networkBackend: netavark
networkBackendInfo:
backend: netavark
dns:
package: aardvark-dns-1.10.0-1.fc40.x86_64
path: /usr/libexec/podman/aardvark-dns
version: aardvark-dns 1.10.0
package: netavark-1.10.3-3.fc40.x86_64
path: /usr/libexec/podman/netavark
version: netavark 1.10.3
ociRuntime:
name: crun
package: crun-1.15-1.fc40.x86_64
path: /usr/bin/crun
version: |-
crun version 1.15
commit: e6eacaf4034e84185fd8780ac9262bbf57082278
rundir: /run/user/1000/crun
spec: 1.0.0
+SYSTEMD +SELINUX +APPARMOR +CAP +SECCOMP +EBPF +CRIU +LIBKRUN +WASM:wasmedge +YAJL
os: linux
pasta:
executable: /usr/bin/pasta
package: passt-0^20240510.g7288448-1.fc40.x86_64
version: |
pasta 0^20240510.g7288448-1.fc40.x86_64
Copyright Red Hat
GNU General Public License, version 2 or later
<https://www.gnu.org/licenses/old-licenses/gpl-2.0.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law.
remoteSocket:
exists: true
path: /run/user/1000/podman/podman.sock
rootlessNetworkCmd: pasta
security:
apparmorEnabled: false
capabilities: CAP_CHOWN,CAP_DAC_OVERRIDE,CAP_FOWNER,CAP_FSETID,CAP_KILL,CAP_NET_BIND_SERVICE,CAP_SETFCAP,CAP_SETGID,CAP_SETPCAP,CAP_SETUID,CAP_SYS_CHROOT
rootless: true
seccompEnabled: true
seccompProfilePath: /usr/share/containers/seccomp.json
selinuxEnabled: true
serviceIsRemote: false
slirp4netns:
executable: /usr/bin/slirp4netns
package: slirp4netns-1.2.2-2.fc40.x86_64
version: |-
slirp4netns version 1.2.2
commit: 0ee2d87523e906518d34a6b423271e4826f71faf
libslirp: 4.7.0
SLIRP_CONFIG_VERSION_MAX: 4
libseccomp: 2.5.5
swapFree: 8588095488
swapTotal: 8589930496
uptime: 1h 43m 33.00s (Approximately 0.04 days)
variant: ""
plugins:
authorization: null
log:
- k8s-file
- none
- passthrough
- journald
network:
- bridge
- macvlan
- ipvlan
volume:
- local
registries:
search:
- registry.fedoraproject.org
- registry.access.redhat.com
- docker.io
...
version:
APIVersion: 5.1.0
Built: 1716940800
BuiltTime: Wed May 29 08:00:00 2024
GitCommit: ""
GoVersion: go1.22.3
Os: linux
OsArch: linux/amd64
Version: 5.1.0
Yup. Same for me. The feature layer is built from scratch.
I have instead been using DevPod's implementation of the devcontainer specification and it does re-use the cache with a podman provider setup when doing a workspace rebuild/reset.
That may be a possible trail to look into, just unsure at this point if the issue should be under buildah or the devcontainer extension/cli.
I will test again with the latest version of the devcontainer extension/cli and podman as it has been a while since I used such setup.
Description When building devcontainer with features, Podman doesn't use the cached layers for features, which makes it very slow.
Steps to reproduce the issue:
Note: if the local server only has Docker installed (e.g. OSX with Docker Desktop), you may need to create shells script named
podman
thatexec docker "$@"
, andpodman-compose
thatexec docker-compose "$@"
. I don't know whether this is strictly needed, but I'll include it here just in case you encounter errors. Note: I think it should also reproducible if you just start VSCode on remote server, but I haven't tested this setup.Dev Containers: Add Dev Container Configuration Files...
, follow the steps to create a dev container. Make sure add some features when creating it. On my side, I chose 'Ubuntu', 'jammy' and then added 'Go' feature.Dev Containers: Rebuild Container
. And you will observe the layers are rebuilt again and not cached.I've tried on OSX with Docker Desktop, the same command (except it uses docker) is run and the layers are cached when rebuilding:
The above command is just for reference and will not run on your environment.
Describe the results you received: The feature layer is not cached and needs a rebuild.
Describe the results you expected: The feature layer should be cached and no rebuild is needed.
Output of
rpm -q buildah
orapt list buildah
:Output of
buildah version
:Output of
podman version
if reporting apodman build
issue:*Output of `cat /etc/release`:**
Output of
uname -a
:Output of
cat /etc/containers/storage.conf
: