Stream: git-wasmtime

Topic: wasmtime / Issue #358 OCI-compatible proposal for wrapper...


view this post on Zulip Wasmtime GitHub notifications bot (Mar 29 2020 at 15:48):

dippynark commented on Issue #358:

@leonwanghui just found that project too and have been working on getting it working again - planning to use the wasmer go bindings though: https://github.com/wasmerio/go-ext-wasm

should make the implementation simpler as they'll be no need to shell out to another binary. Not sure if that was a design decision, but since they'll be a mutliple shim instances I can't see an issue with that.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 29 2020 at 16:43):

tschneidereit commented on Issue #358:

Microsoft's Krustlet project might be a better approach, depending on details of your use case.

If that doesn't work, note that we'll have Go bindings for Wasmtime soon, too.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2020 at 02:14):

dippynark commented on Issue #358:

@tschneidereit that looks really cool - would like to have an integration with the upstream kubelet too which yeah the wasmtime bindings would help with for sure, but that projects looks like a good alternative.

Have had some trouble today understanding how the sandbox pod fits into the picture - it seems the shim is expected to support running the pause container, which does not match with running wasm with go bindings, but going to carry on with it

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2020 at 02:14):

dippynark edited a comment on Issue #358:

@tschneidereit that looks really cool - would like to have an integration with the upstream kubelet too which yeah the wasmtime bindings would help with for sure, but that projects looks like a good alternative.

Have had some trouble today understanding how the sandbox container fits into the picture - it seems the shim is expected to support running the pause container, which does not match with running wasm with go bindings, but going to carry on with it

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2020 at 02:15):

dippynark edited a comment on Issue #358:

@tschneidereit that looks really cool - would like to have an integration with the upstream kubelet too which yeah the wasmtime bindings would help with for sure, but that projects looks like a good alternative.

Have had some trouble today understanding how the sandbox container fits into the picture - it seems the shim is expected to support running the pause container, which does not match too well with running wasm with go bindings, but am going to carry on with it

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2020 at 18:02):

technosophos commented on Issue #358:

@dippynark Feel free to drop in on our Krustlet project. I think we are going to start holding public Zoom meetings in the next few weeks, since we've gotten to this point where we are doing lots and lots of one-off calls that would better be served by a community dev chat sorta thing.

We did a CRI implementation as well, and started work on a containerd shim, but hit up against design trade-offs that we did not like. So we went back to implementing a kubelet that viewed WASM as its first-class runtime. There has been some talk about attempting to re-visit CRI (and maybe do a CRI v2) to make it less OCI/Docker-centric (it makes _really_ strong assumptions about the runtime). But that is probably a 2+ year project. Krustlet is, for us, a chance to try to solve the problem today.

Since @radu-matei wrote his post last November, we've also been pretty successful storing WASM modules in at least some OCI registries. That route is looking promising.

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2020 at 19:39):

thomastaylor312 commented on Issue #358:

I think we are going to start holding public Zoom meetings in the next few weeks, since we've gotten to this point where we are doing lots and lots of one-off calls that would better be served by a community dev chat sorta thing.

We are starting to next week! We have the link and time in the README

view this post on Zulip Wasmtime GitHub notifications bot (Mar 30 2020 at 22:54):

dippynark commented on Issue #358:

@technosophos that could be good, will see next week - would be interested in hearing what the design tradeoffs were?

I've made some progress building on top the existing project, I have just got it running Docker containers like this using a wasm runtime like this. I guess some difficulties will come trying to implement things like exec.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 02 2020 at 18:10):

technosophos commented on Issue #358:

Sorry, the links you left above are broken @dippynark, and I could not read them. @thomastaylor312 is definitely the best resource with whom to discuss this, though.

view this post on Zulip Wasmtime GitHub notifications bot (Apr 02 2020 at 21:03):

dippynark edited a comment on Issue #358:

@technosophos that could be good, will see next week - would be interested in hearing what the design tradeoffs were?

I've made some progress building on top the existing project, I have just got it running Docker containers like this using a wasm runtime like this. I guess some difficulties will come trying to implement things like exec.


Last updated: Nov 22 2024 at 17:03 UTC