-
Notifications
You must be signed in to change notification settings - Fork 183
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.
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
Shim Connect method returns VM-internal information #210
Comments
Yeah. Not so sure what people want to do with the PIDs. The .proto file doesn't explain the semantics much. |
Yeah, just going by its use in their code, containerd internally appears to use it to check if a shim is still alive after the containerd daemon restarts. If they exposed it to clients in the future (I don't think it is currently) I'd suspect it could be used for monitoring the process so they can know directly if something goes wrong and the shim exits unexpectedly or something like that. I'm now also wondering if in the short term we should replace the implementation of this method with one that returns a |
Now we return ErrNotImplemented instead. I'd like keep this issue open until we figure out a long-term solution (or decide that returning the error is the long-term solution). |
It's probably the time to formally address this issue now for containerd v1.6.0 release. The task creation logic here needs a PID from shim. And the new logic in shim layer will call This essentially breaks the entire task creation process in fc-cd. The error is:
|
…kips Move soft_fail back to master tests
The
Connect
method served by a v2 runtime service is supposed to provide the Shim's PID and a given Task's PID.Right now, our host-side runtime shim just forwards the request to the VM Agent, so the results returned are specific to the VM, which is a bit surprising for a caller outside the VM to receive (they can't really do much with a PID that exists inside the VM):
firecracker-containerd/runtime/service.go
Lines 938 to 950 in c0abc8b
At the time of this writing, the
Connect
API doesn't appear to be exposed to containerd clients; it does however appear to be used by containerd internally in order to reconnect to a shim after the containerd service restarts.There needs to be more investigation to determine the proper fix here. I suspect it would make sense to at least return the host-side Shim PID instead of the VM Agent PID, however it's less immediately clear what we should return as the Task PID since there is not a host-side PID for the task. Depending on how containerd ends up actually using that Task PID it may or may not make sense to just return the PID of the VM as the Task PID.
The text was updated successfully, but these errors were encountered: