k8s: guest-pull: initContainer with shared volume fails #9668
Labels
Projects
Comments
fidencio
added
bug
fidencio
added a commit
to fidencio/kata-containers
that referenced
this issue
May 19, 2024
This is another one that is related to initContainers not being properly handled with the guest image pulling. Let's skip it for now as we have kata-containers#9668 to track it down. Signed-off-by: Fabiano Fidêncio <fabiano.fidencio@intel.com>
4 tasks
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 22, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 22, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 22, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 22, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 22, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 22, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 22, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 22, 2024
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 <chengyu.zhu@intel.com>
fidencio
pushed a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 22, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 23, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 23, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 23, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 23, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 23, 2024
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 <chengyu.zhu@intel.com>
ChengyuZhu6
added a commit
to ChengyuZhu6/kata-containers
that referenced
this issue
May 23, 2024
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 <chengyu.zhu@intel.com>
wainersm
added a commit
to wainersm/kata-containers
that referenced
this issue
May 29, 2024
This test fails with qemu-coco-dev configuration and guest-pull image pull. Issue: kata-containers#9668 Signed-off-by: Wainer dos Santos Moschetta <wainersm@redhat.com>
ryansavino
added a commit
to AdithyaKrishnan/kata-containers
that referenced
this issue
Jun 1, 2024
This test is failing due to the initContainers not being properly handled with the guest image pulling. Issue tracked here: kata-containers#9668 Skipping for now. Signed-Off-By: Ryan Savino <ryan.savino@amd.com>
ryansavino
added a commit
to AdithyaKrishnan/kata-containers
that referenced
this issue
Jun 1, 2024
This test is failing due to the initContainers not being properly handled with the guest image pulling. Issue tracked here: kata-containers#9668 Skipping for now. Signed-Off-By: Ryan Savino <ryan.savino@amd.com>
ryansavino
added a commit
to AdithyaKrishnan/kata-containers
that referenced
this issue
Jun 1, 2024
This test is failing due to the initContainers not being properly handled with the guest image pulling. Issue tracked here: kata-containers#9668 Skipping for now. Signed-Off-By: Ryan Savino <ryan.savino@amd.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Another one related to initContainers (see also #9666 and #9664).
Bats output:
The text was updated successfully, but these errors were encountered: