Open ldoktor opened 1 day ago
When creating a normal pod with workingDir pointing to a non-existent location it happily creates the directory for us. This is not happening with peer-pods.
workingDir
cat << \EOF | oc apply -f - apiVersion: v1 kind: Pod metadata: name: ldoktor labels: app: http-server-app spec: runtimeClassName: kata-remote containers: - name: http-server image: busybox command: ["sh", "-xc", "pwd"] workingDir: /foo/bar restartPolicy: Never EOF
cloud-api-adaptor 04ccaf60aec8eb4e855226273c09e3e24a80e098
None
oc describe pod/ldoktor ... Events: Type Reason Age From Message ---- ------ ---- ---- ------- Normal Scheduled 2m21s default-scheduler Successfully assigned user-ns2/ldoktor to ip-192-168-13-255.ec2.internal Normal Pulling 5s kubelet Pulling image "busybox" Normal Pulled 5s kubelet Successfully pulled image "busybox" in 121ms (121ms including waiting). Image size: 2167126 bytes. Normal Created 5s kubelet Created container http-server Warning Failed 2s kubelet Error: failed to create containerd task: failed to create shim task: ENOENT: No such file or directory Stack backtrace: 0: anyhow::error::<impl core::convert::From<E> for anyhow::Error>::from 1: rustjail::container::do_init_child 2: rustjail::container::init_child 3: kata_agent::main 4: std::sys_common::backtrace::__rust_begin_short_backtrace 5: std::rt::lang_start Stack backtrace: 0: anyhow::kind::Adhoc::new 1: rustjail::sync_with_async::read_async::{{closure}} 2: <rustjail::container::LinuxContainer as rustjail::container::BaseContainer>::start::{{closure}} 3: kata_agent::rpc::AgentService::do_create_container::{{closure}}::{{closure}}.10322 4: <kata_agent::rpc::AgentService as protocols::agent_ttrpc_async::AgentService>::create_container::{{closure}} 5: <protocols::agent_ttrpc_async::CreateContainerMethod as ttrpc::asynchronous::utils::MethodHandler>::handler::{{closure}} 6: ttrpc::asynchronous::server::HandlerContext::handle_msg::{{closure}} 7: <ttrpc::asynchronous::server::ServerReader as ttrpc::asynchronous::connection::ReaderDelegate>::handle_msg::{{closure}}::{{closure}} 8: tokio::runtime::task::raw::poll 9: tokio::runtime::scheduler::multi_thread::worker::Context::run_task 10: tokio::runtime::task::raw::poll 11: std::sys_common::backtrace::__rust_begin_short_backtrace 12: core::ops::function::FnOnce::call_once{{vtable.shim}} 13: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at ./rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9 14: <alloc::boxed::Box<F,A> as core::ops::function::FnOnce<Args>>::call_once at ./rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/alloc/src/boxed.rs:2007:9 15: std::sys::unix::thread::Thread::new::thread_start at ./rustc/82e1608dfa6e0b5569232559e3d385fea5a93112/library/std/src/sys/unix/thread.rs:108:17: unknown
Describe the bug
When creating a normal pod with
workingDir
pointing to a non-existent location it happily creates the directory for us. This is not happening with peer-pods.How to reproduce
CoCo version information
cloud-api-adaptor 04ccaf60aec8eb4e855226273c09e3e24a80e098
What TEE are you seeing the problem on
None
Failing command and relevant log output