Open dropte opened 11 months ago
Hey, thanks for reporting this!
I think if you increase the CDI log verbosity with something like
kubectl set env deployment cdi-operator \
--namespace="${cdi_namespace}" \
--containers='cdi-operator' \
VERBOSITY="3"
We should get the actual stdout/stderr of the untar command
Lightly redacted output:
I1114 14:05:16.309950 1 importer.go:103] Starting importer
I1114 14:05:16.309997 1 importer.go:172] begin import process
I1114 14:05:16.310038 1 http-datasource.go:392] Attempting to HEAD "https://<url>/example.tar" via http client
I1114 14:05:16.598432 1 http-datasource.go:424] Content length: 2048
I1114 14:05:16.598446 1 http-datasource.go:327] Attempting to get object "https://<url>/example.tar" via http client
I1114 14:05:16.671028 1 data-processor.go:356] Calculating available size
I1114 14:05:16.671075 1 data-processor.go:368] Checking out file system volume size.
I1114 14:05:16.671103 1 data-processor.go:376] Request image size not empty.
I1114 14:05:16.671114 1 data-processor.go:381] Target size 96112640.
I1114 14:05:16.671149 1 format-readers.go:112] constructReaders: checking compression and archive formats
I1114 14:05:16.671163 1 format-readers.go:121] found header of type "tar"
I1114 14:05:16.671171 1 data-processor.go:255] New phase: TransferDataDir
I1114 14:05:16.671180 1 util.go:207] begin untar to /data...
I1114 14:05:16.671187 1 util.go:213] running untar cmd: [/usr/bin/tar --preserve-permissions --no-same-owner -xvC /data]
I1114 14:05:16.672780 1 util.go:220] STDOUT
./
./example
I1114 14:05:16.672787 1 util.go:221] STDERR
/usr/bin/tar: .: Cannot utime: Operation not permitted
/usr/bin/tar: .: Cannot change mode to rwxr-xr-x: Operation not permitted
/usr/bin/tar: Exiting with failure status due to previous errors
E1114 14:05:16.672793 1 util.go:222] exit status 2
E1114 14:05:16.672806 1 data-processor.go:251] exit status 2
unable to untar files from endpoint
kubevirt.io/containerized-data-importer/pkg/importer.(*HTTPDataSource).Transfer
pkg/importer/http-datasource.go:169
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).initDefaultPhases.func3
pkg/importer/data-processor.go:191
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessDataWithPause
pkg/importer/data-processor.go:248
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessData
pkg/importer/data-processor.go:157
main.handleImport
cmd/cdi-importer/importer.go:178
main.main
cmd/cdi-importer/importer.go:144
runtime.main
GOROOT/src/runtime/proc.go:250
runtime.goexit
GOROOT/src/runtime/asm_amd64.s:1594
Unable to transfer source data to target directory
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).initDefaultPhases.func3
pkg/importer/data-processor.go:193
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessDataWithPause
pkg/importer/data-processor.go:248
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessData
pkg/importer/data-processor.go:157
main.handleImport
cmd/cdi-importer/importer.go:178
main.main
cmd/cdi-importer/importer.go:144
runtime.main
GOROOT/src/runtime/proc.go:250
runtime.goexit
GOROOT/src/runtime/asm_amd64.s:1594
E1114 14:05:16.672884 1 importer.go:181] exit status 2
unable to untar files from endpoint
kubevirt.io/containerized-data-importer/pkg/importer.(*HTTPDataSource).Transfer
pkg/importer/http-datasource.go:169
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).initDefaultPhases.func3
pkg/importer/data-processor.go:191
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessDataWithPause
pkg/importer/data-processor.go:248
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessData
pkg/importer/data-processor.go:157
main.handleImport
cmd/cdi-importer/importer.go:178
main.main
cmd/cdi-importer/importer.go:144
runtime.main
GOROOT/src/runtime/proc.go:250
runtime.goexit
GOROOT/src/runtime/asm_amd64.s:1594
Unable to transfer source data to target directory
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).initDefaultPhases.func3
pkg/importer/data-processor.go:193
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessDataWithPause
pkg/importer/data-processor.go:248
kubevirt.io/containerized-data-importer/pkg/importer.(*DataProcessor).ProcessData
pkg/importer/data-processor.go:157
main.handleImport
cmd/cdi-importer/importer.go:178
main.main
cmd/cdi-importer/importer.go:144
runtime.main
GOROOT/src/runtime/proc.go:250
runtime.goexit
GOROOT/src/runtime/asm_amd64.s:1594
Note that this is on nodes with the device_ownership_from_security_context
set to true at the containerd level.
I see. Maybe as non-root it would make sense for us to use these
-m, --touch
Don't extract file modified time.
--no-overwrite-dir
Preserve metadata of existing directories.
/assign akalenyu
Is this still an issue for you?
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
/remove-lifecycle stale
I've encountered the same issue.
Content of TAR that causes the error:
$ tar -tv --numeric-owner -f archive.tar
drwxr-xr-x 2009/2000 0 2024-04-05 05:33 ./
drwxr-xr-x 2009/2000 0 2024-04-05 05:33 ./blah/
-rw-r--r-- 2009/2000 12 2024-04-05 05:33 ./blah/README
drwxr-xr-x 2009/2000 0 2024-04-05 05:33 ./foo/
Content of the TAR that doesn't cause an error:
$ tar -tv --numeric-owner -f archive2.tar
drwxr-xr-x 2009/2000 0 2024-04-05 05:33 blah/
-rw-r--r-- 2009/2000 12 2024-04-05 05:33 blah/README
drwxr-xr-x 2009/2000 0 2024-04-05 05:33 foo/
Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale
.
Stale issues rot after an additional 30d of inactivity and eventually close.
If this issue is safe to close now please do so with /close
.
/lifecycle stale
/remove-lifecycle stale issue definitely still around
Issue isn't limited to archives containing links.
The parameters used by CDI when calling tar
won't work with all PVC/StorageClass and Pod security context due to ownership.
It looks like the current importer Pod is tailored for importing disk images meant to be consumed by libvirt/qemu. But maybe that's a limiting factor when just trying to import an archive
with random files to be mounted with VirtIO disk and not as a VM disk.
What happened: When extracting a Tarball with top level relative links, extraction will fail. Chaging the tarball to contain only absolute links makes it succeed.
What you expected to happen: DataVolume should be created and return success
How to reproduce it (as minimally and precisely as possible): Steps to reproduce the behavior. Create a tarball from a directory:
Host the files via http. Create DataVolumes:
output from importer for rel:
Additional context: Using Rook-Ceph as the storage provider, but can reproduce running importer container on local storage via docker. Seems to have worked ok in 1.52.0. Possibly related to permissions running as non-root user in container.
Environment:
kubectl get deployments cdi-deployment -o yaml
): 1.57.0kubectl version
): v1.26.8uname -a
): Linux e8451be7-6ce0-4581-8d7b-4ecff846abde-jx84w-pool3-f873b2ad-cxwds 5.15.0-1017-aws #21-Ubuntu SMP Fri Aug 5 11:10:45 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux