-
Notifications
You must be signed in to change notification settings - Fork 90
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
Support V3 containerd task service and Sandboxers #385
Comments
Sorry if these are silly questions:
|
I think that's where we'd need to focus
No
Yep
We probably should for compatability sake... but this is going to start getting hairy, I think, with sandboxers. |
I believe rust-extensions added the sandbox apis a couple releases ago: containerd/rust-extensions#145 |
Hi, I'm the maintainer of Kuasar, we have forked rust-extesions and made a "sandbox crate" that implements The current origin Sandbox APIs is immature and incomplete, so we are planning to promote our forked containerd. To achive this, we have presented many times on containerd community meeting introduing "sandboxer"(please refer to meeting record) and got approval from many containerd maintainers. There is a tracking issue with v2.0 milestone: containerd/containerd#9431 After this issue, we also expect to push the "sandbox crate" to the origin repo. I think we can contribute together if runwasi plans to support Sandbox API too. |
That would be coolio, @Burning1020 ! |
If I understand this correctly, the issue containerd/containerd#9431 is to track progress for the "sandboxer" APIs, which are different from the sandbox APIs that included in containerd 2.0. Are the sandboxer APIs expected to be included in 2.0 release as well or seperate? Would appreciate some clarifications 🙏 @Burning1020 |
The API is part of it, exactly #9736 and #9903, the others are some code refactoring.
We all(including containerd maintainers) expect to have sandbox feature released in 2.0 as disscussed in last community meeting, the maintainers are trying best to review while it's heavy workloads. Wolud you guys like to help in review? |
I would love to! I think @cpuguy83 is already actively involved in this part, correct me if I am wrong? Just to clarify, the sandboxer APIs and sandbox APIs are part of the same feature in containerd 2.0, right? |
@Mossaka Thank you. They are in the same feature, the sandboxer APIs should also be involved in 2.0 without which the sandbox feature is hard to use. |
The 'shared' mode in runwasi is not actively maintained and tested. This commit is removing it. The 'shared' mode will soon be replaced with the Sandboxer API described in containerd#385 Signed-off-by: jiaxiao zhou <jiazho@microsoft.com>
The 'shared' mode in runwasi is not actively maintained and tested. This commit is removing it. The 'shared' mode will soon be replaced with the Sandboxer API described in containerd#385 Signed-off-by: jiaxiao zhou <jiazho@microsoft.com>
In containerd 1.7 the v3 task service was introduced.
In v3 both ttrpc and grpc are supported, choosing what RPC to use should definitely take into account memory overhead.
There's no real rush here, but V3 does buy us some simplified logic in bootstrapping the shim and support for "sandboxer" services.
"Sandboxer" can do a number of things, the immediate benefit is we don't have to have this logic that guesses that the first container sent to the shim (with a cri label) is actually the "pause" container.
Instead it leaves that implementation detail up to the sandboxer.
It would also make the "shared" mode as described in our readme a first class citizen.
Related:
The text was updated successfully, but these errors were encountered: