Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

k8s: guest-pull: "Test readonly volume for pods" fails #9667

Open
fidencio opened this issue May 19, 2024 · 0 comments
Open

k8s: guest-pull: "Test readonly volume for pods" fails #9667

fidencio opened this issue May 19, 2024 · 0 comments
Labels
area/guest-pull bug Incorrect behaviour needs-review Needs to be assessed by the team.
Projects
Issue backlog

Comments

@fidencio
Copy link
Member

fidencio commented May 19, 2024 •
edited 

# Events:
#   Type     Reason   Age   From     Message
#   ----     ------   ----  ----     -------
#   Normal   Pulling  82s   kubelet  Pulling image "busybox"
#   Normal   Pulled   81s   kubelet  Successfully pulled image "busybox" in 739ms (739ms including waiting)
#   Normal   Created  81s   kubelet  Created container busybox-file-volume-container
#   Warning  Failed   79s   kubelet  Error: failed to create containerd task: failed to create shim task: failed to handle layer: hasher sha256: channel: send failed SendError { .. }: unknown
# pod "test-file-volume" deleted

Well, the volume has to be exposed to the VM somehow ... and this is yet not supported.
This will be the very same case for all the tests related to volumes, in the same way we have the limitations for firecracker.

The tests affected by this limitation are:

  • k8s-credentials-secrets.bats
  • k8s-file-volume.bats
  • k8s-inotify.bats
  • k8s-nested-configmap-secret.bats
  • k8s-projected-volume.bats
  • k8s-volume.bats
@fidencio fidencio added bug Incorrect behaviour needs-review Needs to be assessed by the team. area/guest-pull labels May 19, 2024
@fidencio fidencio mentioned this issue May 19, 2024
Open
@wainersm wainersm mentioned this issue May 20, 2024
Open
4 tasks
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 22, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
639d9ca 
Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats

Fixes: kata-containers#9664 kata-containers#9666 kata-containers#9667 kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 22, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
3518c81 
Revert

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-kill-all-process-in-container.bats
- k8s-sysctls.bats

Fixes: kata-containers#9664 kata-containers#9666 kata-containers#9667 kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 22, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
1efffe8 
Revert code logic in 462051b

Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the system searches for the existing configuration, which resides in the
guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>. Consequently, when
the InitContainer finishes its task and terminates, the directory ceases to exist. As a result, during the creation of the application container,
the OCI spec and process information cannot be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-kill-all-process-in-container.bats
- k8s-sysctls.bats

Fixes: kata-containers#9664 kata-containers#9666 kata-containers#9667 kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
@ChengyuZhu6 ChengyuZhu6 mentioned this issue May 22, 2024
Draft
@katacontainersbot katacontainersbot moved this from To do to In progress in Issue backlog May 22, 2024
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 22, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
37004bd 
Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the system searches for the existing configuration, which resides in the
guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>. Consequently, when
the InitContainer finishes its task and terminates, the directory ceases to exist. As a result, during the creation of the application container,
the OCI spec and process information cannot be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-kill-all-process-in-container.bats
- k8s-sysctls.bats

Fixes: kata-containers#9664 kata-containers#9666 kata-containers#9667 kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 22, 2024
@ChengyuZhu6
Remove agent/image: merge container spec for images pulled inside guest
96c7f5e 
Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the image service searches for the existing configuration,
which resides in the guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>.
Consequently, when the InitContainer finishes its task and terminates, the directory ceases to exist.
As a result, during the creation of the application container, the OCI spec and process information cannot
be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-kill-all-process-in-container.bats
- k8s-sysctls.bats

Fixes: kata-containers#9664 kata-containers#9666 kata-containers#9667 kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 22, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
677b518 
Revert code logic in 462051b

Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the image service searches for the existing configuration,
which resides in the guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>.
Consequently, when the InitContainer finishes its task and terminates, the directory ceases to exist.
As a result, during the creation of the application container, the OCI spec and process information cannot
be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-kill-all-process-in-container.bats
- k8s-sysctls.bats

Fixes: kata-containers#9664 kata-containers#9666 kata-containers#9667 kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 22, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
066d772 
Revert code logic in 462051b

Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the image service searches for the existing configuration,
which resides in the guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>.
Consequently, when the InitContainer finishes its task and terminates, the directory ceases to exist.
As a result, during the creation of the application container, the OCI spec and process information cannot
be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-kill-all-process-in-container.bats
- k8s-sysctls.bats

Fixes: kata-containers#9664   kata-containers#9666   kata-containers#9667   kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 22, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
37ff037 
Revert code logic in 462051b

Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the image service searches for the existing configuration,
which resides in the guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>.
Consequently, when the InitContainer finishes its task and terminates, the directory ceases to exist.
As a result, during the creation of the application container, the OCI spec and process information cannot
be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-kill-all-process-in-container.bats
- k8s-sysctls.bats

Fixes: kata-containers#9664
Fixes: kata-containers#9666
Fixes: kata-containers#9667
Fixes: kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
fidencio pushed a commit to ChengyuZhu6/kata-containers that referenced this issue May 22, 2024
@ChengyuZhu6 @fidencio
Revert agent/image: merge container spec for images pulled inside guest
4a4fa55 
Revert code logic in 462051b

Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the image service searches for the existing configuration,
which resides in the guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>.
Consequently, when the InitContainer finishes its task and terminates, the directory ceases to exist.
As a result, during the creation of the application container, the OCI spec and process information cannot
be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-kill-all-process-in-container.bats
- k8s-sysctls.bats

Fixes: kata-containers#9664
Fixes: kata-containers#9666
Fixes: kata-containers#9667
Fixes: kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 23, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
703cb37 
Revert code logic in 462051b

Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the image service searches for the existing configuration,
which resides in the guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>.
Consequently, when the InitContainer finishes its task and terminates, the directory ceases to exist.
As a result, during the creation of the application container, the OCI spec and process information cannot
be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-kill-all-process-in-container.bats
- k8s-sysctls.bats

Fixes: kata-containers#9664
Fixes: kata-containers#9666
Fixes: kata-containers#9667
Fixes: kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 23, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
b48144e 
Revert code logic in 462051b

Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the image service searches for the existing configuration,
which resides in the guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>.
Consequently, when the InitContainer finishes its task and terminates, the directory ceases to exist.
As a result, during the creation of the application container, the OCI spec and process information cannot
be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-sysctls.bats

Fixes: kata-containers#9666
Fixes: kata-containers#9667
Fixes: kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 23, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
0393408 
Revert code logic in 462051b

Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the image service searches for the existing configuration,
which resides in the guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>.
Consequently, when the InitContainer finishes its task and terminates, the directory ceases to exist.
As a result, during the creation of the application container, the OCI spec and process information cannot
be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-sysctls.bats

Fixes: kata-containers#9666
Fixes: kata-containers#9667
Fixes: kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 23, 2024
@ChengyuZhu6
Revert agent/image: merge container spec for images pulled inside guest
300006f 
Revert code logic in 462051b

Let me explain why:

In our previous approach, we implemented guest pull by passing PullImageRequest to the guest.
However, this method  resulted in the loss of specifications essential for running the container,
such as commands specified in YAML, during the CreateContainer stage. To address this,
it is necessary to integrate the OCI specifications and process information from the image’s configuration with the container in guest pull.

The snapshotter method does not care this issue. Nevertheless, a problem arises when two containers in the same pod attempt
to pull the same image, like InitContainer. This is because the image service searches for the existing configuration,
which resides in the guest. The configuration, associated with <image name, cid>, is stored in the directory /run/kata-containers/<cid>.
Consequently, when the InitContainer finishes its task and terminates, the directory ceases to exist.
As a result, during the creation of the application container, the OCI spec and process information cannot
be merged due to the absence of the expected configuration file.

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-sysctls.bats

Fixes: kata-containers#9666
Fixes: kata-containers#9667
Fixes: kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 23, 2024
@ChengyuZhu6
agent/image: refactor code in guest pull
1ac6e5c 
Refactor code in guest pull

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-sysctls.bats

Fixes: kata-containers#9666
Fixes: kata-containers#9667
Fixes: kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
ChengyuZhu6 added a commit to ChengyuZhu6/kata-containers that referenced this issue May 23, 2024
@ChengyuZhu6
agent/image: refactor code in guest pull
e72d085 
Refactor code in guest pull

Fix tests:
- k8s-credentials-secrets.bats
- k8s-file-volume.bats
- k8s-nested-configmap-secret.bats
- k8s-projected-volume.bats
- k8s-volume.bats
- k8s-shared-volume.bats
- k8s-sysctls.bats

Fixes: kata-containers#9666
Fixes: kata-containers#9667
Fixes: kata-containers#9668

Signed-off-by: ChengyuZhu6 <[email protected]>
wainersm added a commit to wainersm/kata-containers that referenced this issue May 30, 2024
@wainersm
tests/k8s: skip file volume tests for qemu-coco-dev
3e18fe7 
This test fails with qemu-coco-dev configuration and guest-pull image pull.

Issue: kata-containers#9667
Signed-off-by: Wainer dos Santos Moschetta <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
area/guest-pull bug Incorrect behaviour needs-review Needs to be assessed by the team.
Projects
Issue backlog
  
In progress
Milestone
No milestone
Development

No branches or pull requests
1 participant
@fidencio