-
Notifications
You must be signed in to change notification settings - Fork 128
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
A question: Why not directly return when AddFd fail in RunPodSandbox? #720
Comments
Hmmm... If AddFd failed during RunPodSandbox CreateContainer should fail on the beginning (around there: https://github.com/Mirantis/virtlet/blob/master/pkg/manager/runtime.go#L314), because sandbox metadata should not land in metadata store at the end of RunPodSandbox (https://github.com/Mirantis/virtlet/blob/master/pkg/manager/runtime.go#L171). |
The version is release v1.0. log, There are some my analysis. and is chinese, you can ignore it.
|
The problem is that you are using an old version and some things are already fixed (like corrected cni handling, libvirt calls covered with locks, so there should bo no more errors like |
Can you tell me the PR which we solved the issue on? |
Issue with handling cni was fixed by #665. After that mentioned by you on the beginning call to CreateContainer after failed AddFd will not be done. Still #719 imo fixes handling of calls to tapmanager from vmwrapper (ok, PR description is incorrect because it's not only about AddFd but all RPC using tapmanager client) which were not fixed by both of above mentioned PRs. |
Thanks, @jellonek I will try new version later. Hope to be solved:) |
Now, we continue to do CreateContainer when AddFd is failed in RunPodSandbox. After all kubelet will trigger delete all.
I think it is meaningless, and it introduce some new problem.
we should directly return when AddFd is failed in RunPodSandbox.
refer to #718 #719
The text was updated successfully, but these errors were encountered: