Docker+Wasm Integration

Tell us about your request
As a developer, I would like to have the ability to build, share, and run Wasm applications using Docker Desktop.
Which service(s) is this request for?
Docker Desktop
Additional context
This post is intended to gather feedback on the new Docker+Wasm integration. Feel free to share issues or ideas on how we can make the product better!

I probably do not understand this very well. But I will still ask.
In the browser, we use imports functions to allow the WASM binary to interact with the browser environment, for example, by passing console.log as an import, the WASM module can use that imported function to log things in the console in the browser. The concept can be further exploited to expose a full set of graphics functions to allow a WASM binary to run a legacy game (stuff I am really into). Giving the game low-level OpenGL access to an HTML canvas element.
How does this work in Docker+WASM with the WasmEdge runtime. Do I have to write a WasmEdge plugin to be able to create this link to the outside world? Is this technically a part of the so-called containerd shim provided by WasmEdge? What kind of functionality is provided by the WasmEdge runtime? I looked at the API documentation but there was nothing there that resembled, for example, networking functionality or anything of this sort.
I would like to understand this stuff more and how to make the most out of it. Thanks!

Hi @diraneyya! Glad you asked!
WasmEdge implements the WASI standard that gives you access to the outside world. There is still active work happening on this specification. You can follow Wasm spec work more broadly as it happens under the Bytecode Alliance.
@juntao and his team can give you more information about the WasmEdge runtime specifically.

Thanks @chris-crone and hi @diraneyya !
Yes, WASI specifies how WebAssembly Runtimes, including WasmEdge, access the operating system. That includes standard POSIX / libc APIs to access the file system / network etc.
So, you can just create a Rust program to open a file or open a socket connection or write to the console (eg print!() and dbg!() macros), compile it to wasm32/wasi target, and it will run in WasmEdge. See
https://wasmedge.org/book/en/write_wasm/rust.html
You can also do this with other languages supported in WasmEdge including JavaScript.
https://wasmedge.org/book/en/write_wasm/js/quickstart.html

Hey folks - Heads up that I'm not able to get the tech preview to run on an intel Mac. I am a Docker Desktop user and the stable version works fine. Let me know if you would like any debug information to assist. I'm really excited to see this and would love to try it out

Hi @lachie83! Sorry to hear it isn't working. We'll reach out via email to get more details

Thanks Chris - happy to help.

@lachie83, @chris-crone, FWIW - I was able to run it on first shot.
Here are more details in case they help debug:
$ docker --version
Docker version 20.10.18, build b40c2f6
$
$ neofetch --stdout | egrep 'OS|Host|Kernel'
OS: macOS 11.6 20G165 x86_64
Host: MacBookPro16,1
Kernel: 20.6.0

Looks like similar hardware and Kernal, different OS
$ neofetch --stdout | egrep 'OS|Host|Kernel'
OS: macOS 11.7.1 20G918 x86_64
Host: MacBookPro16,1
Kernel: 20.6.0
$ docker --version
Docker version 20.10.18, build b40c2f6

Well done @mikesir87 and team, this is very exciting work. I'm looking forward to seeing this work as a driver for WASM through the ecosystem, e.g., resolving/landing https://github.com/opencontainers/image-spec/pull/964, and seeing https://wasmedge.org/book/en/use_cases/kubernetes/docker/containerd.html filled out.
I for one welcome our new micro-microservice overlords.
I wasn't mentioned in the blog post, but where is io.containerd.wasmedge.v1? I saw a couple of older projects implementing the containerd Runtime V2 shim for other WASM runtimes, (which is what I understand was done here based on the blog post), but couldn't find this work on GitHub or the wider Internet.
So I'm assuming it's not public yet, but will be?

Can someone confirm this is the same containerd shim used under https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-pools right?
Just want to make sure when developing a generic WASI app it runs in Docker WASM.

Hi @TBBle
Thank you for your kind words. Please do let us know if you encounter any issues. We cannot wait to see the Wasm microservices you create. :)
The containerd shim for WasmEdge is here:
https://github.com/second-state/runwasi
We are in the process of merging it upstream to DeisLabs runwasi project, and hopefully eventually to the containerd project itself.

It is not the same. But all standard compliant WASI app should work in both environments. If not,  let us know. :)

Can someone confirm this is the same containerd shim used under https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-pools right?
Just want to make sure when developing a generic WASI app it runs in Docker WASM.

Just chiming in quickly to confirm what @juntao says here. The wasmedge team did in fact use the core https://github.com/deislabs/runwasi shim to quickly provide wasi support in containerd with the wasmedge runtime and we're thrilled it worked perfectly for the Docker Desktop preview. As a result, @tigerinus, our path for bringing the two together and moving the shim upstream to the containerd project is pretty easy and we look forward to working on that together.
In fact, the community's collective work on https://github.com/deislabs/runwasi -- including enabling any number of open source runtimes like SecondState's wasmedge -- will continue rapidly. If you're interested, you can track that repo (which we hope to move into the containerd repo as soon as we can). Using the Docker Desktop+wasm preview with the https://github.com/second-state/runwasi will not be any problem for using future shims. It's a great way to get started here!

Great work everyone and very exciting!
I'd be keen to see the following from Docker Desktop going forward:

If we're going to package Wasm binaries inside OCI images for the foreseeable... may be a better way than layering the Wasm module on top of a scratch base image in a Dockerfile? It feels a bit hacky
docker buildx build to eventually create native Wasm artifacts rather than shoe-horn them into OCI images
Support for more Wasm runtimes and the Docker Desktop UI make it easy to pick and install them
Let's get this containerd shim approach into K8s

it is hacky. We'll end up using OCI Artifact graphs, which we need for signature, attestation, and sbom information anyway. But it's fine, as there are plenty of hacks that work fine in this space.
My guess is yes, but that's a Docker thing. LOTS of things will build to wasm, but docker buildx build is a special kind of sweetness.
Already in process. (Docker, SecondState, Deislabs at MS to start....)
Already in process. (ditto)

Anything else, @nigelpoulton ? I mean, make it at least HARD.

Mind you, on 1 I am of course speaking for myself here, not Docker. :-)

Quick question: can we leverage HPA to autoscale WASM module like traditonal PoD?

you will be able to use all the normal k8s mechanisms with either version of https://github.com/deislabs/runwasi as we roll forward. At the moment, however, telemetry isn't working well -- we have to emit things to enable this. We should soon have a new version of the runwasi shim (and secondstatewill work on theirs until we coalesce) that will emit all the telemetry needed for any k8s scaling scenario.
The ONLY thing that will not yet work is mixed containers/wasm inside one pod. This precludes the usage of service messes in k8s for the time being. Nailing that scenario is in the backlog but we have no roadmap timing for that yet. Ironically, as service messes have lots of headspace we have very little evidence that lots of people use them: https://www.datadoghq.com/container-report/ says only about 10% of people use meshes..... ymmv.

Thx @squillace for your reply.
Before, we played around with deislabs/krustlet . With Krustlet, we are able to deploy WASM module into K8s cluster. But,  we are NOT able to eanble HPA feature (for autoscaling).
Two questions:

Since both deislabs/krustlet and deislabs/runwasi  are from  Deislabs, what's the difference?
what's difference between  deislabs/runwasi  and secondstate's (i.e. WasmEdge Runtime-based solution)?

in reverse order:
2. https://github.com/docker/roadmap/issues/426#issuecomment-1298353493 pretty much explains it. SecondState used the deislabs runwasi to implement wasmedge because it has special features that aren't available elsewhere. You can see the diff here. But the larger point is that this is merely an early set of experiments by us all in the wasm ecosystem. Both SecondState and Microsoft (Deislabs) will be working to bring multiple runtimes to the runwasi shim as we go forward. You might need to know now that there's a difference, but we assume that in the future you won't need to.

Krustlet was our second attempt at deislabs (after modeling them as a CRI implementation in https://github.com/deislabs/wok) to integrate wasm into Kubernetes smoothly. Krustlet DID work, as you note, but it brought with it a ton of overhead as well as making it harder to model wasm as pods easily. In the end, it is used as a rust kubelet and it implements a rust oci-distribution crate (which will be very useful moving to OCI Artifacts) as well as krator, the state engine. But neither the Fermyon maintainers, nor the Cosmonic maintainer, nor we here at Microsoft are still working on krustlet. It's just too much effort to bring it up to production quality and then you still have to treat your nodes like pets with taints and tolerations and all that messiness.

Turns out that ContainerD shims are right abstraction for that. Krustlet might still become very useful for key situations.
Are you using Krustlet successfully aside from the autoscaling?

I note that mixed containers/wasm is also an important use case to implement sidecars for telemetry collection, e.g. Datadog Agent, OTel Agent, Jaeger Agent.

Oh yes -- because that's how they work now. With Wasm components, you'd be moving toward an in-proc OTEL component that exports such information. Sidecars are horrible unless you have only one or two -- not because the model doesn't work, but because it's just harder to use. BUT we use them!!!! For example, we've test implemented Dapr sidecars as components and WOW does that change things. It's almost as if kubernetes is good. :-P
That said....

I'll note that anecdotally the last two k8s-based applications I was involved in building both relied on auto-injected telemetry sidecars

I'm expecting that we'll make this happen. But it's not going to happen this month. First, we make these solid, enable componentized runtimes so that people can choose theirs to use, and upstream the shim work to the ContainerD project in the CNCF.

in reverse order: 2. #426 (comment) pretty much explains it. SecondState used the deislabs runwasi to implement wasmedge because it has special features that aren't available elsewhere. You can see the diff here. But the larger point is that this is merely an early set of experiments by us all in the wasm ecosystem. Both SecondState and Microsoft (Deislabs) will be working to bring multiple runtimes to the runwasi shim as we go forward. You might need to know now that there's a difference, but we assume that in the future you won't need to.

Krustlet was our second attempt at deislabs (after modeling them as a CRI implementation in https://github.com/deislabs/wok) to integrate wasm into Kubernetes smoothly. Krustlet DID work, as you note, but it brought with it a ton of overhead as well as making it harder to model wasm as pods easily. In the end, it is used as a rust kubelet and it implements a rust oci-distribution crate (which will be very useful moving to OCI Artifacts) as well as krator, the state engine. But neither the Fermyon maintainers, nor the Cosmonic maintainer, nor we here at Microsoft are still working on krustlet. It's just too much effort to bring it up to production quality and then you still have to treat your nodes like pets with taints and tolerations and all that messiness.

Turns out that ContainerD shims are right abstraction for that. Krustlet might still become very useful for key situations.
Are you using Krustlet successfully aside from the autoscaling?

Other features works well. BTW, I recalled there is open issue mentioning this limitation too: https://github.com/krustlet/krustlet/issues/470

Hey guys, great work!
Have one question - how do I pass arguments to the underlying runtime? In my case I want to access files on my local machine. Now, if I do this with wasmedge separately I'd just have to add a say --dir /:/ to have access to everything from WASI.
I tried mounting with -v when I run the "wasm container" but that was not enough.
E.g. using singlestore-labs' python I could do something like this
alexandrov:\>wasmedge --dir /:$(pwd) --env PYTHONPATH=/python311.zip/python3.11 --env PYTHONHOME=/python311.zip/python3.11 ./python3.11.wasm -c 'import os; print(os.listdir(""));'
['python3.11.wasm', 'python311.zip']
alexandrov:\>tree
.
├── python3.11.wasm
└── python311.zip

0 directories, 2 files

The key thing here is --dir/$(pwd) along with the PYTHONPATH and PYTHONHOME variables.
So I built myself an image that has just python3.11.wasm and python311.zip but couldn't make it work.
Even running the interpreter fails as it does not pick the env variables. Tried passing them to the container, as usual, but that did not propagate them to the wasm module.
docker run -d --runtime=io.containerd.wasmedge.v1 --platform wasi/wasm32 python-wasm -v /:$(pwd)/python-wasm -e PYTHONPATH=/python311.zip/python3.11 -e PYTHONHOME=/python311.zip/python3.11

Any help or ideas would be greatly appreciated.

Hi @assambar
The Wasm file is packaged in a SCRATCH OCI image. It has access to the / directory of the container. So you can mount a directory to the container and then access it from inside the Wasm app.
Let us know if it works. Thanks!

Hi @juntao

It has access to the / directory of the container. So you can mount a directory to the container and then access it from inside the Wasm app.

I still could not get this behavior to work for me. Created a simple repository with a repro here - https://github.com/assambar/lsr-wasm-docker
Just using a rust program, which lists recursively from /, when I run it inside the container I get nothing. I added more info on what I'm doing in the repo above.
This is the version I have
docker --version
Docker version 20.10.18, build b40c2f6

Thanks!

@assambar I just opened a PR to make this work, see here: https://github.com/second-state/runwasi/pull/23
My output with this code:
$ make demo-contents-not-seen
cargo build --release
    Finished release [optimized] target(s) in 0.00s
docker build --platform wasi/wasm -f Dockerfile . -t lsr-wasm
[+] Building 0.0s (6/6) FINISHED
 => [internal] load .dockerignore                                                                              0.0s
 => => transferring context: 2B                                                                                0.0s
 => [internal] load build definition from Dockerfile                                                           0.0s
 => => transferring dockerfile: 168B                                                                           0.0s
 => [internal] load build context                                                                              0.0s
 => => transferring context: 2.69kB                                                                            0.0s
 => CACHED [1/2] COPY target/wasm32-wasi/release/lsr.wasm /                                                    0.0s
 => CACHED [2/2] COPY target/wasm32-wasi/release/ /t-w-r/                                                      0.0s
 => exporting to image                                                                                0.0s
 => => exporting layers                                                                                0.0s
 => => exporting manifest sha256:96faf496b2dcc33348802c8c77c3f17164f04f697cbb3eda5943b0ce8abdaf92              0.0s
 => => exporting config sha256:3c909aecd3975ec564e5b68ca45454dbdead748bce263801115cb452d87c9e35                0.0s
 => => naming to docker.io/library/lsr-wasm:latest                                                             0.0s
 => => unpacking to docker.io/library/lsr-wasm:latest                                                          0.0s
docker run --name lsr-docker-run --runtime=io.containerd.wasmwasi.v1 --platform wasi/wasm lsr-wasm
Starting from root_dir "/"
/
/lsr.wasm
/etc
/etc/hostname
/etc/hosts
/etc/resolv.conf
/t-w-r
/t-w-r/lsr.d
/t-w-r/build
/t-w-r/lsr.wasm
/t-w-r/deps
/t-w-r/deps/libwalkdir-e3683a9a82f3afb8.rmeta
/t-w-r/deps/lsr-7938fa61da9ece80.wasm
/t-w-r/deps/libsame_file-3faf241ee7934e00.rmeta
/t-w-r/deps/walkdir-e3683a9a82f3afb8.d
/t-w-r/deps/libwalkdir-e3683a9a82f3afb8.rlib
/t-w-r/deps/libsame_file-3faf241ee7934e00.rlib
/t-w-r/deps/lsr-7938fa61da9ece80.d
/t-w-r/deps/same_file-3faf241ee7934e00.d
/t-w-r/.cargo-lock
/t-w-r/.fingerprint
/t-w-r/.fingerprint/same-file-3faf241ee7934e00
/t-w-r/.fingerprint/same-file-3faf241ee7934e00/invoked.timestamp
/t-w-r/.fingerprint/same-file-3faf241ee7934e00/dep-lib-same-file
/t-w-r/.fingerprint/same-file-3faf241ee7934e00/lib-same-file
/t-w-r/.fingerprint/same-file-3faf241ee7934e00/lib-same-file.json
/t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8
/t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8/invoked.timestamp
/t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8/lib-walkdir
/t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8/dep-lib-walkdir
/t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8/lib-walkdir.json
/t-w-r/.fingerprint/lsr-7938fa61da9ece80
/t-w-r/.fingerprint/lsr-7938fa61da9ece80/invoked.timestamp
/t-w-r/.fingerprint/lsr-7938fa61da9ece80/bin-lsr.json
/t-w-r/.fingerprint/lsr-7938fa61da9ece80/dep-bin-lsr
/t-w-r/.fingerprint/lsr-7938fa61da9ece80/bin-lsr
/t-w-r/examples
/t-w-r/incremental
docker export lsr-docker-run -o lsr-contents.tar
tar -tvf lsr-contents.tar
drwxr-xr-x 0/0               0 2022-11-23 17:57 etc/
-rw-r--r-- 0/0               0 2022-11-23 17:57 etc/hostname
-rw-r--r-- 0/0               0 2022-11-23 17:57 etc/hosts
-rw-r--r-- 0/0               0 2022-11-23 17:57 etc/resolv.conf
-rwxrwxr-x 0/0         2185909 2022-11-23 17:56 lsr.wasm
drwxr-xr-x 0/0               0 2022-11-23 17:56 t-w-r/
-rw-rw-r-- 0/0               0 2022-11-23 17:56 t-w-r/.cargo-lock
drwxrwxr-x 0/0               0 2022-11-23 17:56 t-w-r/.fingerprint/
drwxrwxr-x 0/0               0 2022-11-23 17:56 t-w-r/.fingerprint/lsr-7938fa61da9ece80/
-rw-rw-r-- 0/0              16 2022-11-23 17:56 t-w-r/.fingerprint/lsr-7938fa61da9ece80/bin-lsr
-rw-rw-r-- 0/0             418 2022-11-23 17:56 t-w-r/.fingerprint/lsr-7938fa61da9ece80/bin-lsr.json
-rw-rw-r-- 0/0              24 2022-11-23 17:56 t-w-r/.fingerprint/lsr-7938fa61da9ece80/dep-bin-lsr
-rw-rw-r-- 0/0              48 2022-11-23 17:56 t-w-r/.fingerprint/lsr-7938fa61da9ece80/invoked.timestamp
drwxrwxr-x 0/0               0 2022-11-23 17:56 t-w-r/.fingerprint/same-file-3faf241ee7934e00/
-rw-rw-r-- 0/0               8 2022-11-23 17:56 t-w-r/.fingerprint/same-file-3faf241ee7934e00/dep-lib-same-file
-rw-rw-r-- 0/0              48 2022-11-23 17:56 t-w-r/.fingerprint/same-file-3faf241ee7934e00/invoked.timestamp
-rw-rw-r-- 0/0              16 2022-11-23 17:56 t-w-r/.fingerprint/same-file-3faf241ee7934e00/lib-same-file
-rw-rw-r-- 0/0             376 2022-11-23 17:56 t-w-r/.fingerprint/same-file-3faf241ee7934e00/lib-same-file.json
drwxrwxr-x 0/0               0 2022-11-23 17:56 t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8/
-rw-rw-r-- 0/0               8 2022-11-23 17:56 t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8/dep-lib-walkdir
-rw-rw-r-- 0/0              48 2022-11-23 17:56 t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8/invoked.timestamp
-rw-rw-r-- 0/0              16 2022-11-23 17:56 t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8/lib-walkdir
-rw-rw-r-- 0/0             430 2022-11-23 17:56 t-w-r/.fingerprint/walkdir-e3683a9a82f3afb8/lib-walkdir.json
drwxrwxr-x 0/0               0 2022-11-23 17:56 t-w-r/build/
drwxrwxr-x 0/0               0 2022-11-23 17:56 t-w-r/deps/
-rw-rw-r-- 0/0           55414 2022-11-23 17:56 t-w-r/deps/libsame_file-3faf241ee7934e00.rlib
-rw-rw-r-- 0/0           39295 2022-11-23 17:56 t-w-r/deps/libsame_file-3faf241ee7934e00.rmeta
-rw-rw-r-- 0/0<PHONE_NUMBER>-11-23 17:56 t-w-r/deps/libwalkdir-e3683a9a82f3afb8.rlib
-rw-rw-r-- 0/0<PHONE_NUMBER>-11-23 17:56 t-w-r/deps/libwalkdir-e3683a9a82f3afb8.rmeta
-rw-rw-r-- 0/0             222 2022-11-23 17:56 t-w-r/deps/lsr-7938fa61da9ece80.d
-rwxrwxr-x 0/0         2185909 2022-11-23 17:56 t-w-r/deps/lsr-7938fa61da9ece80.wasm
-rw-rw-r-- 0/0            1023 2022-11-23 17:56 t-w-r/deps/same_file-3faf241ee7934e00.d
-rw-rw-r-- 0/0            1691 2022-11-23 17:56 t-w-r/deps/walkdir-e3683a9a82f3afb8.d
drwxrwxr-x 0/0               0 2022-11-23 17:56 t-w-r/examples/
drwxrwxr-x 0/0               0 2022-11-23 17:56 t-w-r/incremental/
-rw-rw-r-- 0/0             117 2022-11-23 17:56 t-w-r/lsr.d
hrwxrwxr-x 0/0               0 2022-11-23 17:56 t-w-r/lsr.wasm link to t-w-r/deps/lsr-7938fa61da9ece80.wasm
docker rm lsr-docker-run
lsr-docker-run
rm lsr-contents.tar

@rumpl Thanks for the quick fix and merge into main. I managed to build and use this locally with containerd.
However, I cannot seem to find the proper way to do this with docker-desktop + wasm. Where do you place your re-built containerd-shim-wasmedge-v1 binary to make it work?
I'm using Windows with WSL2 backend, so maybe that's the issue here, but still wanted to ask.
Thanks!

@assambar This will be available in the next version of Docker Desktop that will be released next week.

I have installed the docker desktop preview and the wasmedge docker shim. When I run the docker + wasm example, I encountered the following error:
Using default tag: latest
latest: Pulling from michaelirwin244/wasm-example
operating system is not supported

And this is my docker version and my os:
$ docker --version
Docker version 20.10.21, build baeda1f
$ neofetch --stdout | egrep 'OS|Host|Kernel'
OS: Ubuntu 20.04.4 LTS x86_64
Host: CVM 3.0
Kernel: 5.4.0-109-generic

Dear @jungan21, re: https://github.com/docker/roadmap/issues/426#issuecomment-1325192701.

Beside Autoscaling, are there any other known limitations? We can't wait to roll out this features to our Production env :)
If you take security and compliance seriously, then it is NOT anywhere near production quality yet. Here is the implementation list for OCI compliance; while not all are actually required for solidity and confidence, a good portion ARE. https://github.com/deislabs/runwasi/issues/23. It appears that we've already made great progress thanks to @juntao's team: https://github.com/deislabs/runwasi/pull/26. And a good portion of the OCI work appears possible due to an offer from a community member.

How long? If the world spins perfectly, half a year. If it doesn't, DEFINITELY within the year.

Suppose we have K8s as our Application Hosting Platform, to enable user/developer to be able to deploy to WASM-based Application (i.e. WASM Module) to our K8s env, is there any special settings/configuraiotns required for my K8s cluster?

Your distro will need to bootstrap the shim onto the nodes. For example, using spin and slight shims with AKS Azure does that for you with the az aks nodepool add command: https://learn.microsoft.com/en-us/azure/aks/use-wasi-node-pools. If you want a k3s example, have a look at: https://github.com/deislabs/containerd-wasm-shims/blob/main/deployments/k3d/README.md#how-to-run-the-example. There will be a cluster-api template, too.
For most people, the distro will handle this.

all I have to do is to package WASM file/module in a docker image (i..e. SCRATCH OCI Image)?
At the moment, yes. Use docker buildx and the wasi/wasm target out of tooling courtesy. :-) and it's likely that within the year you'll be able to use the OCI Artifacts work that Docker Hub just announced to deliver the same workloads.

Another question: Once the Docker image (containing WASM file) is deployed to K8s, it's running in a Container like other tradiiotnal non-wasm Docker image? from user's perspective, it's totally transparent?

NO -- the shim does NOT run in a container in the normal sense. The scratch container is only used to deliver the artifacts; once the shim pulls the image, it extracts the artifacts and lays them into the namespace and invokes the runtime, passing them as arguments. This means that a) the wasm sandbox is used to handle requests, but in addition you will ALSO get the standard cgroups and namespace and other security support that a container runtime normally has. Double the security boundaries, double the fun.
Does that all make sense?

The scratch container is only used to deliver the artifacts; once the shim pulls the image, it extracts the artifacts and lays them into the namespace and invokes the runtime, passing them as arguments.

If the runtime is getting all the same namespace/cgroup setup that a container normally gets, this sounds exactly like "a container in the normal sense", or at least much closer than something like kata-containers which uses different isolation technology.
I had understood the difference being that a traditional container:

sets up the filesystem layout (actually mostly handled by the snapshotter earlier)
forks into the require namespaces
execs the target binary with the target arguments and environment

while the runwasi approach:

sets up the filesytem layout (I assumed this was also done earlier by the snapshotter, but it sounds like the goal is to not use the snapshotter at all, but have WASM blobs in the content store which the shim pulls as required)
forks into the required namespaces
loads the target WASM executable and enters it with the target arguments and environment

Are there other differences we'd need to be aware of?

@assambar This will be available in the next version of Docker Desktop that will be released next week.

That's a great news! Where should I subscribe to get access to that?

Hi @TBBle,

If the runtime is getting all the same namespace/cgroup setup that a container normally gets, this sounds exactly like "a container in the normal sense", or at least much closer than something like kata-containers which uses different isolation technology.

if using posix kernel features is all that's required to be a container, then everything that uses them is a container. :-) I'd put it a different way, but obviously ymmv. wasm is a vm spec. Just like other vm specs. In that sense, the inner processes do not use syscalls directly. This is the fundamentally differentiating concept between katacontainers, gvisor/firecracker, jvms/mscorlib, wasm, and "docker containers". IMHO.
What all vm-style "containers" do is create an inner sandbox that possesses everything necessary to run the process, but the inner process does not touch anything outside the sandbox. Of course, unless the sandbox runtime gives permission to do so! So it's possible to have a "secure" wasm destroy the host system if the host system gives it kernel access. Yay! So don't do that. In this sense, it absolutely IS much closer to a katacontainer-style protection but based on a virtual syscall system (wasi) and not on posix or any specific one. Furthermore, one can limit what syscalls the module can even use; this is much harder to do the closer to the underlying system you get. (if you have to bake different node images, it's harder.)
When you ask, what else "we'd need to be aware of" I'm not clear what you'd like to know! Are you asking about the difference between runwasi and runc shims? or crun? or https://github.com/kata-containers/runtime/issues/485? or these kinds of things?

if using posix kernel features is all that's required to be a container, then everything that uses them is a container.

I'd tend to go wider than that: Things that are managed by containerd runtime shims are containers. ^_^
Not everything that uses the namespace APIs (which aren't POSIX, are they? I thought they were Linux-specific...) is a container, but I expect at this point that the overwhelming majority of in-field usage of those APIs is for containerisation.
Anyway, your comment makes sense. I hadn't really thought about WASM as a VM in this context, and see that it's closer to katacontainers than namespace-based containers in underlying tech.

As far as "differences we'd need to be aware of", this was coming from the same user-experience side as the original question, that given the three dot-points I listed seemed to be nicely in parallel if you replace "forks into..." with "enters an isolated sandbox", and hence mostly-ignorable by the user, I don't understand why the answer to the question

Once the Docker image (containing WASM file) is deployed to K8s, it's running in a Container like other traditional non-wasm Docker image? from user's perspective, it's totally transparent?

was "No".
It seems to be transparent, in the same way that from a user's perspective, kata-containers is mostly transparent to the user: You provided an appropriate image reference in, a PodSpec, that image's process is now executing, and doing its job, interacting with other processes in its Pod and nominally isolated from other Pods (barring bugs or known limitations in the specific sandbox tech), and the CRI interactions are consistent across techs, providing consistent behaviours from kubelet up.
So my question was along the lines of: what other things does runwasi do differently enough to catch a k8s user (application deployer) unawares? I'm mostly interested in fundamental differences myself, i.e. things that will remain different, rather that current known limitations, e.g., mixed WASM/non-WASM Pods, since the "for now" state was well-described earlier in the same answer.
From the above, my existing understanding was that the user-facing differences would all be abstracted away in the image format and the containerd configuration for the relevant CRI runtime_handler field, both only interesting to the user at initial Pod creation-time.

in reverse order: 2. #426 (comment) pretty much explains it. SecondState used the deislabs runwasi to implement wasmedge because it has special features that aren't available elsewhere. You can see the diff here. But the larger point is that this is merely an early set of experiments by us all in the wasm ecosystem. Both SecondState and Microsoft (Deislabs) will be working to bring multiple runtimes to the runwasi shim as we go forward. You might need to know now that there's a difference, but we assume that in the future you won't need to.

Krustlet was our second attempt at deislabs (after modeling them as a CRI implementation in https://github.com/deislabs/wok) to integrate wasm into Kubernetes smoothly. Krustlet DID work, as you note, but it brought with it a ton of overhead as well as making it harder to model wasm as pods easily. In the end, it is used as a rust kubelet and it implements a rust oci-distribution crate (which will be very useful moving to OCI Artifacts) as well as krator, the state engine. But neither the Fermyon maintainers, nor the Cosmonic maintainer, nor we here at Microsoft are still working on krustlet. It's just too much effort to bring it up to production quality and then you still have to treat your nodes like pets with taints and tolerations and all that messiness.

Turns out that ContainerD shims are right abstraction for that. Krustlet might still become very useful for key situations.
Are you using Krustlet successfully aside from the autoscaling?

Hi @squillace , I am wondering why WOK didn't work? Or anything in krustlet is better? I do some research and found it should be capable to do that thing using CRI.

So my question was along the lines of: what other things does runwasi do differently enough to catch a k8s user (application deployer) unawares? I'm mostly interested in fundamental differences myself, i.e. things that will remain different, rather that current known limitations, e.g., mixed WASM/non-WASM Pods, since the "for now" state was well-described earlier in the same answer.

@TBBle
As far as I know, runwasi is still in its infancy. Only basic small functions are available yet. That is where users may be surprised.
We have not yet added features such as rootless, which is becoming commonplace these days. You can follow this issue for more information. I will help support it.
https://github.com/deislabs/runwasi/issues/23

@TBBle:
Oh, I see what you're getting at now. Yes, from the user's pov it's like a container, a katacontainer, and so on. It operates differently, but YES, a user should just deploy yaml and it should look pretty much the same. The feature set is different, which is why we do it, but the experience is mostly the same -- as we think it should be.
To then get at your driving question:

what other things does runwasi do differently enough to catch a k8s user (application deployer) unawares? I'm mostly interested in fundamental differences myself, i.e. things that will remain different, rather that current known limitations, e.g., mixed WASM/non-WASM Pods, since the "for now" state was well-described earlier in the same answer.

Off the top of my head, I'd say the following things are likely to remain different-ish:

sidecars are likely best implemented as in-process wasm components. We've done this experimentally with dapr, and it eliminates grpc overhead and crunches down size to KBs. Alternatively, sidecars can be ported to component interfaces, too, presupposing we find a nice way to do pods with both types of processes in them. Larger point: there will continue to be a decision we and devs have to make for a while about mixing and matching containers and modules there. At least the tradeoffs will be very clear!
app host artifact graphs. At the moment, the way we're approaching the design is to enable multiple artifacts to be deployed in one "pod", which in the native world is usually a config file and a host, and then any other modules/binaries necessary for the app. These are currently bundled in a scratch container and then extracted as we've described. In the normal K8s world, you'd have to make the config file either yaml metadata or a config map or mount the file into the process and the other binaries would be their own services in some way. This means you have to know how to make two different apps: the "native" one that can run standalone anywhere and also the k8s version. We'd like to enable and preserve both mechanisms so that the agility of Docker build buildx/push/k apply -f just works without repackaging AND ALSO enable professionals who like to streamline all their ops into k8s-only formats to choose and it works both ways.

There are other differences to be aware of, and they affect where you'll use wasm and where you will use containers. Containers are built for long running processes; wasm, for short, fast, quick processes where you are not going to accumulate lots of state. So the requirement to scale out with wasm is going to be far less, as each request allocates memory, starts a module, and then reclaims that memory. Container workloads do not behave the same way. Somewhere there's a very good Fermyon post where they illustrate the lower, steadier work state consumption for a wasm workload versus a container one. Neither are better, but as we learn more about wasm in this environment we'll have a better understanding of how resources are consumed.
Hope this helps!

in response to @MrZLeo:

Hi @squillace , I am wondering why WOK didn't work? Or anything in krustlet is better? I do some research and found it should be capable to do that thing using CRI.

in reverse order: CRI is so completely hard coded to containers themselves that we got exhausted faking apis that have no meaning. Full stop. In theory, a CRI that is a "compute" runtime interface and not a container one would be perfect here. Kubernetes is designed to have gears replaced; this is one area that needs a CRI v2. :-)
Krustlet worked fine, but it models nodes so that they become "special". If you need taints and tolerations for workloads, ultimately those nodes are now pets. Of course, some cattle are more "petty" than others; still, the direction we want to move is toward a nodeless or node-agnostic experience. Krustlet, however, does have lots of potential for special cases. I'd love to use it to experiment with disconnected and semiconnected nodes at some point. Why not?

in response to @MrZLeo:

Hi @squillace , I am wondering why WOK didn't work? Or anything in krustlet is better? I do some research and found it should be capable to do that thing using CRI.

in reverse order: CRI is so completely hard coded to containers themselves that we got exhausted faking apis that have no meaning. Full stop. In theory, a CRI that is a "compute" runtime interface and not a container one would be perfect here. Kubernetes is designed to have gears replaced; this is one area that needs a CRI v2. :-)
Krustlet worked fine, but it models nodes so that they become "special". If you need taints and tolerations for workloads, ultimately those nodes are now pets. Of course, some cattle are more "petty" than others; still, the direction we want to move is toward a nodeless or node-agnostic experience. Krustlet, however, does have lots of potential for special cases. I'd love to use it to experiment with disconnected and semiconnected nodes at some point. Why not?

@squillace
Thanks for reply! Learn the story behind it helps me a lot. But I am still confused about nodeless design here. Does it mean we don't need abstraction of Pod in WASM?
As far as I am concerned, Pod == a WASM Virtual Machine. Am I wrong? :(

ah yes: https://kubernetes.io/docs/reference/command-line-tools-reference/kubelet/. A pod is a representation of a process, more or less -- there can be multiple processes (containers) in a pod. A node is a vm, more or less (because it could be baremetal and so on). All of these can be faked or modified if you know what you're doing. But generally a node is a vm and a pod is a container(s)/process.

@vsilent You will need Docker Desktop 4.15 with containerd support turned on in settings. Thanks.

@MrZLeo happy new year (by some counts)! You still have the abstraction of pods not because we couldn't have gotten rid of them but because a) they're normal for k8s people to think about a parent process or "app", and b) we want a normal k8s "view" of the world.
What we're aiming at is to give you merely "another" container-type experience but without worrying about which type of node it's running on. So it's not really a nodeless experience, and in that I misspoke. But "node-agnostic" experience is the correct way to think about it. For each pod you have "at least" one wasm runtime instance, yes. You could have more, but at least one.

Tell us about your request As a developer, I would like to have the ability to build, share, and run Wasm applications using Docker Desktop.
Which service(s) is this request for? Docker Desktop
Additional context This post is intended to gather feedback on the new Docker+Wasm integration. Feel free to share issues or ideas on how we can make the product better!

 Is it possible for the WASM containers to run without a Linux VM?

I think this is in theory possible but would probably require significant changes in Docker Desktop -- correct me if I am wrong here -- I understand Docker Desktop is set up to run everything in a VM on MacOS at this time.

 Is it possible for the WASM containers to run without a Linux VM?

I understand Docker Desktop is set up to run everything in a VM on MacOS at this time.

As far as I know, yes.
I was going to add "There's Docker Desktop on Linux", but apparently that is running inside a VM as well. It seems that Docker Desktop is quite entangled in running inside a VM 😞.

I wasn't aware that Docker Desktop for Linux uses a VM; I guess that's to isolate it hard from the local OS and, e.g. local containerd or dockerd processes. Docker Desktop for Windows doesn't use a VM for either Linux (if using WSL2 mode) nor Windows-native containers, only for the older HyperV-base Linux container support.
I don't know how connected/separated the different Docker Desktop platform versions are, so maybe this setup is specific to Windows, but if they are the same code-base then Docker Desktop does support non-VM-hosted runtimes at some level.

when I am trying to run wasm application using docker I am getting like this..
Using default tag: latest
latest: Pulling from michaelirwin244/wasm-example
operating system is not supported
I am trying docker +wasm in ubuntu linux OS. Here are my docker version and my os details:
$neofetch --stdout | egrep 'OS|Host|Kernal'
os: Ubuntu 20.04.4 LTS x86_64
Host: 20TBS2S100 ThinkPad E14 Gen 2
Kernal: 5.15.0-46-generic
can any one try to sort out this issue please

You "docker version" didn't actually say what version of Docker you're using. You need to be running Docker Desktop, not just Docker Engine (see here for the difference), and have enabled the containerd image store beta per the Docker+Wasm (Beta) instructions.
You also didn't show the command you ran, but I assume it was docker run -dp 8080:8080 --name=wasm-example --runtime=io.containerd.wasmedge.v1 --platform=wasi/wasm32 michaelirwin244/wasm-example from the first usage example.

Thanks the docker run is working. Previously I installed docker engine instead of docker desktop  that's why the error is pop up.By using docker desktop it is working fine...

I was following the steps on the recent blog post about Preview 2 on Windows WSL2.
I can successfully run $ docker run --rm --runtime=io.containerd.wasmedge.v1  --platform=wasi/wasm secondstate/rust-example-hello:latest
But I get an error with the following:
$ docker run --runtime=io.containerd.spin.v1 -p 3000:80 docker run --runtime=io.containerd.spin.v1 -p 3000:80 my-cms
docker: Error response from daemon: failed to create task for container: failed to start shim: failed to resolve runtime path: runtime "io.containerd.spin.v1" binary not installed "containerd-shim-spin-v1": file does not exist: unknown.
ERRO[0000] error waiting for container: context canceled
```

Let me know if I should open an issue elsewhere instead of adding to this thread.

I assume you're talking about https://www.docker.com/blog/announcing-dockerwasm-technical-preview-2/?
My first guess is that you didn't install the tech preview build from that page, or at least it's not being used; the first command-line would also work in the current Docker Desktop release, and the error you're getting suggests that the shim binary is not installed. If this is the case, you should also find that the wasmtime example gives a similar error.

@steren are you sure you have the preview 2?
Also the line looks weird, you have run twice:
$ docker run --runtime=io.containerd.spin.v1 -p 3000:80 docker run --runtime=io.containerd.spin.v1 -p 3000:80 my-cms

Sorry for the typo, I confirm that I got the same error when typing $ docker run --runtime=io.containerd.spin.v1 -p 3000:80  bartholomew-cms
I missed from the blog post that I needed to install a special build of Docker Desktop (the links are below the image, making them easy to miss.
The bit.ly link for Windows in the blog post (http://bit.ly/3IVw7fE) doesn't download anything for me. is it a valid link?

OK, looks like if I follow the bit.ly redirect, I get this URL: https://desktop-stage.docker.com/win/main/amd64/99998/Docker Desktop Installer.exe

I've seen a lot of Docker + Wasm applications on the internet, but I'm sorry to say that I think the wasm runtime that Docker currently integrates with has various problems, such as the one described in this article, [Running docker wasm preview fails tutorial](https://taction.top/serverless/ webassembly/dockerwasmpreview/), it's impossible to run up a full project, and it feels like this feature is simply a toy.
I would like to give feedback that you should integrate wasm runtime like wazero.io, because it is also developed in Go, while other wasm runtimes are in C or C++. This makes it necessary for developers to learn C++ or other programming languages if they want to contribute code. The integration of a runtime implemented in the same type of Go programming language as docker would help developers get started with docker more easily and do secondary development,without dependency on cgo is a good choice!

Tell us about your request As a developer, I would like to have the ability to build, share, and run Wasm applications using Docker Desktop.
Which service(s) is this request for? Docker Desktop
Additional context This post is intended to gather feedback on the new Docker+Wasm integration. Feel free to share issues or ideas on how we can make the product better!

I've seen a lot of Docker + Wasm applications on the internet, but I'm sorry to say that I think the wasm runtime that Docker currently integrates with has various problems, such as the one described in this article : Running docker wasm preview fails tutorial , it's impossible to run up a full project, and it feels like this feature is simply a toy.
I would like to give feedback that you should integrate wasm runtime like wazero.io, because it is also developed in Go, while other wasm runtimes are in C or C++. This makes it necessary for developers to learn C++ or other programming languages if they want to contribute code. The integration of a runtime implemented in the same type of Go programming language as docker would help developers get started with docker more easily and do secondary development,without dependency on cgo is a good choice!

I am all for more runtime support. But just FYI: While Wazero is written in Golang, it does not run Golang apps. You still need TinyGo (or Rust) like every other Wasm runtimes Docker+Wasm already integrates.
Golang support for Wasm may come later this year. But it will require a set of complex Wasm proposals (like Stack switching and GC) that are currently being implemented in wasmtime and WasmEdge.

Tell us about your request As a developer, I would like to have the ability to build, share, and run Wasm applications using Docker Desktop.

Which service(s) is this request for? Docker Desktop

Additional context This post is intended to gather feedback on the new Docker+Wasm integration. Feel free to share issues or ideas on how we can make the product better!

I've seen a lot of Docker + Wasm applications on the internet, but I'm sorry to say that I think the wasm runtime that Docker currently integrates with has various problems, such as the one described in this article : Running docker wasm preview fails tutorial , it's impossible to run up a full project, and it feels like this feature is simply a toy.
I would like to give feedback that you should integrate wasm runtime like wazero.io, because it is also developed in Go, while other wasm runtimes are in C or C++. This makes it necessary for developers to learn C++ or other programming languages if they want to contribute code. The integration of a runtime implemented in the same type of Go programming language as docker would help developers get started with docker more easily and do secondary development,without dependency on cgo is a good choice!

I understood that https://github.com/docker/roadmap/issues/426#issuecomment-1515972699 was talking about contributing to the runtime, rather than Go language support in the runtime.
This whole integration is based on the containerd Runtime Shim v2 which is a TTRPC or GRPC service, so any and all WASM runtimes can be hooked up to implement that service definition. A runtime written in Rust or with existing Rust bindings has the advantage that it can probably be integrated with https://github.com/containerd/runwasi (as WasmEdge and WasmTime already are) and reuse the boilerplate and process management structure implemented there, but that doesn't prevent, e.g. wazero.io from implementing the containerd Runtime Shim v2 API and hence outputting a shim as part of their own CI, as e.g. hcsshim does for Windows containers.
If you want wazero.io integration for example, I'd suggest opening a feature request on their repo, as that would be the best place to maintain such an integration, unless someone wants to build and maintain something like https://github.com/containerd/runwasi in Go, for multiple Go-based WASM runtimes and runtimes with Go bindings instead. (I'm not familiar enough with the Go/WASM ecosystem to know if that would be a good idea or be overengineering.)

I understood that #426 (comment) was talking about contributing to the runtime, rather than Go language support in the runtime.
This whole integration is based on the containerd Runtime Shim v2 which is a TTRPC or GRPC service, so any and all WASM runtimes can be hooked up to implement that service definition. A runtime written in Rust or with existing Rust bindings has the advantage that it can probably be integrated with https://github.com/containerd/runwasi (as WasmEdge and WasmTime already are) and reuse the boilerplate and process management structure implemented there, but that doesn't prevent, e.g. wazero.io from implementing the containerd Runtime Shim v2 API and hence outputting a shim as part of their own CI, as e.g. hcsshim does for Windows containers.
If you want wazero.io integration for example, I'd suggest opening a feature request on their repo, as that would be the best place to maintain such an integration, unless someone wants to build and maintain something like https://github.com/containerd/runwasi in Go, for multiple Go-based WASM runtimes and runtimes with Go bindings instead. (I'm not familiar enough with the Go/WASM ecosystem to know if that would be a good idea or be overengineering.)

Yep, Your understanding is right, the need for a common runtime standard is to allow developers to customize the replacement runtime, not bound by a specific runtime, and designed to be plug-in like, can check the pull structure, and container interface standards similar, thank you. Currently wasm is in the development stage, many languages with gc do not have perfect support, and there is a multi-threaded part of the support plan; currently wasm runtime has many implementations, which is somewhat similar to the initial design of gralvm, are trying to do a generic language virtual machine and runtime.

I am all for more runtime support. But just FYI: While Wazero is written in Golang, it does not run Golang apps. You still need TinyGo (or Rust) like every other Wasm runtimes Docker+Wasm already integrates.
Golang support for Wasm may come later this year. But it will require a set of complex Wasm proposals (like Stack switching and GC) that are currently being implemented in wasmtime and WasmEdge.

Tell us about your request As a developer, I would like to have the ability to build, share, and run Wasm applications using Docker Desktop.

Which service(s) is this request for? Docker Desktop

Additional context This post is intended to gather feedback on the new Docker+Wasm integration. Feel free to share issues or ideas on how we can make the product better!

I've seen a lot of Docker + Wasm applications on the internet, but I'm sorry to say that I think the wasm runtime that Docker currently integrates with has various problems, such as the one described in this article : Running docker wasm preview fails tutorial , it's impossible to run up a full project, and it feels like this feature is simply a toy.
I would like to give feedback that you should integrate wasm runtime like wazero.io, because it is also developed in Go, while other wasm runtimes are in C or C++. This makes it necessary for developers to learn C++ or other programming languages if they want to contribute code. The integration of a runtime implemented in the same type of Go programming language as docker would help developers get started with docker more easily and do secondary development,without dependency on cgo is a good choice!

Yes, there are many runtimes at the moment, wasm many features are still in the early stages, garbage collector and multi-threaded support.

I am all for more runtime support. But just FYI: While Wazero is written in Golang, it does not run Golang apps. You still need TinyGo (or Rust) like every other Wasm runtimes Docker+Wasm already integrates.
Golang support for Wasm may come later this year. But it will require a set of complex Wasm proposals (like Stack switching and GC) that are currently being implemented in wasmtime and WasmEdge.

Tell us about your request As a developer, I would like to have the ability to build, share, and run Wasm applications using Docker Desktop.

Which service(s) is this request for? Docker Desktop

Additional context This post is intended to gather feedback on the new Docker+Wasm integration. Feel free to share issues or ideas on how we can make the product better!

I've seen a lot of Docker + Wasm applications on the internet, but I'm sorry to say that I think the wasm runtime that Docker currently integrates with has various problems, such as the one described in this article : Running docker wasm preview fails tutorial , it's impossible to run up a full project, and it feels like this feature is simply a toy.
I would like to give feedback that you should integrate wasm runtime like wazero.io, because it is also developed in Go, while other wasm runtimes are in C or C++. This makes it necessary for developers to learn C++ or other programming languages if they want to contribute code. The integration of a runtime implemented in the same type of Go programming language as docker would help developers get started with docker more easily and do secondary development,without dependency on cgo is a good choice!

ok, I'm getting to know wasmedge.

the links on the technical preview 2 page seem broken
https://www.docker.com/blog/announcing-dockerwasm-technical-preview-2/
can someone please fix them or alternately send here the link for the linux deb-intel version of it?

Per https://docs.docker.com/desktop/wasm/ I believe it's now part of the main Docker Desktop distribution as a Beta feature. However, as Docker limits who has access to Beta features, it may not be accessible to you. (I recently noticed I couldn't access the Containerd Image Store feature toggle which this one depends on anymore, when I went to test a related fix in buildx).

Oh, duh. Yeah, that's my mistake. Sorry for the confusion.

When using latest (4.20.1) Docker Desktop, building image with --platform=wasi/wasm flag results in the following error, even though the image is still built:
ERROR: failed to solve: no match for platform in manifest sha256:3187cb57f434ae8ba21e9cd78b59cae54b0345bf948bb430d83a3031af82e6ff: not found
It's annoying as this fails the build script we have, but this does not happen in the first Docker Desktop version (4.15.0) where wasm support was provided.

I believe https://github.com/opencontainers/image-spec/pull/1055 is probably relevant (wasip1/wasm for preview1, eventually wasip2/wasm for preview2, and likely only wasi/wasm after GA) :bow:

@suneetnangia , thank you for the report. This's an issue with buildkit: moby/buildkit#3891 As a workaround you can run docker build with --provenance=false or setting the env var BUILDX_NO_DEFAULT_ATTESTATIONS=1

Thanks @jprendes  It worked for me.

Tell us about your request As a developer, I would like to have the ability to build, share, and run Wasm applications using Docker Desktop.
Which service(s) is this request for? Docker Desktop
Additional context This post is intended to gather feedback on the new Docker+Wasm integration. Feel free to share issues or ideas on how we can make the product better!

I've seen a lot of Docker + Wasm applications on the internet, but I'm sorry to say that I think the wasm runtime that Docker currently integrates with has various problems, such as the one described in this article : Running docker wasm preview fails tutorial , it's impossible to run up a full project, and it feels like this feature is simply a toy.
I would like to give feedback that you should integrate wasm runtime like wazero.io, because it is also developed in Go, while other wasm runtimes are in C or C++. This makes it necessary for developers to learn C++ or other programming languages if they want to contribute code. The integration of a runtime implemented in the same type of Go programming language as docker would help developers get started with docker more easily and do secondary development,without dependency on cgo is a good choice!

I've been doing a bit of reading lately about the built-in wasm runtime. their documentation is written very messy, and senior developers understand that the documentation is divided into two categories, the first for the use of tutorials document, the second is the API documentation. And their software promotion and traditional rogue virus software,installed in the case of the user without knowledge of your computer, without the user's permission, similar to the early PC software bundled sales, which is a disgusting behavior, bundled in the docker sales.

Are there docs covering how to run wasm docker apps without requiring Docker Desktop? All the docs at https://docs.docker.com/desktop/wasm seem to assume/require Docker Desktop specifically.
I'm working on adding support for building wasm containers using ko and I'd love to be able to test this functionality in GitHub Actions.

HI @imjasonh
There's an example for enabling and using the wamtime runtime in the doc for Alternative container runtimes.
Hope that helps!

It would be really useful if we could save the wasm file from the image. Currently, it possibly to save the entire OCI image. docker save -o configur.tar cataggar/configur. It would be great if we could do docker save -f confugur.wasm cataggar/configur the particular file for troubleshooting.

@cataggar The easiest method I can see is something like:
docker save cataggar/configur | tar x confugur.wasm

The limitation is that images are stored as tar-streams, so to do what you want, they'd basically have to implement tar x somewhere, along with a bunch of CLI options and syntax for a new command or extra overload on an existing command.
If this was from a running or stopped container rather than an image, docker cp <imagename>:confugur.wasm confugur.wasm should work, if your debugging flow supports that.
That said, this isn't Wasm integration specific, so I'd suggest opening a feature request if you want to actually pursue such a feature in Docker.

I hope the Docker Engine supports wasm, not just Docker Desktop

@Avey777 it does.
Please refer to the following link for the instructions to set it up: https://docs.docker.com/engine/alternative-runtimes/#wasmtime

Any work/timeline on having this as part of Docker Engine and not just Docker Desktop? I am trying to figure out how to run this on the cloud.

Any work/timeline on having this as part of Docker Engine and not just Docker Desktop?
I am trying to figure out how to run this on the cloud, more specifically on GCloud Run where I don't have access to docker daemon. So can't use @jprendes's suggestion.

That link is the instructions for using this with Docker Engine directly, i.e. if you aren't using Docker Desktop.
If you're using Docker Engine managed by someone else, you'll need to raise a feature request with them to offer WASM support. Right now, from their docs, Google Cloud Run only supports Linux x86_64 ABI executables.
Looking around, I'm not convinced Google Cloud Run even uses Docker Engine; from the docs, it is running either in gVisor, or as containers inside some sort of hypervisor.
But either way, this is not something Docker has any say in, you'll have to request it from Google directly. https://issuetracker.google.com/issues/271552514?pli=1 might cover it already, actually. So I'd suggest upvoting that issue, and maybe note that you expect to see something compatible with existing wasip1/wasm images and future revisions, ala https://github.com/opencontainers/image-spec/pull/1055, to maximise support for externally-created images.

Just to add to @TBBle 's great answer, if you are happy using Kubernetes (like GCP Kubernetes), you could try Kwasm

I am not sure if this is the right place to mention this, but I seem to have hit a problem with the tutorial at:
https://docs.docker.com/desktop/wasm
When I run the following, I simply get Hello WasmEdge! as a response, the container shuts down, and nothing loads at http://localhost:8080
 docker run \
  --runtime=io.containerd.wasmedge.v1 \
  --platform=wasi/wasm \
  secondstate/rust-example-hello

To note:

I am on Docker Desktop 4.24.2 (124339)
I have enabled Use containerd for pulling and storing images
I have enabled Enable Wasm

That looks like a documentation issue, your outcome looks correct for that project's documentation.
Try secondstate/rust-example-server instead to see a server in action. Although it is slightly more featureful than this description.
Either way, your setup is working, as you were able to run the WASM-based container. This difference should not prevent you continuing to explore the Docker WASM integration beta.

@TBBle Thank you for the response! I attempted to run this:
docker run \
  --runtime=io.containerd.wasmedge.v1 \
  --platform=wasi/wasm \
  secondstate/rust-example-server

When I did, I got this response:
Listening on http://<IP_ADDRESS>:8080
But when I visit http://<IP_ADDRESS>:8080 or http://localhost:8080 in a browser, nothing loads. Also, in Docker Desktop, the port column for that container isn't showing anything. Apologies if I am missing something obvious!

@johnstonphilip as with any image, you need to expose the port 8080, i.e.,
docker run --rm \
  --runtime=io.containerd.wasmedge.v1 \
  --platform=wasi/wasm \
  -p 8080:8080 \
  secondstate/rust-example-server

then you can do
curl http://localhost:8080

I am not able to get correct  docker stats for wasm container, its always near to 0%.
Also I am not able to
ankit.anand-mbp@BA-00026768 ~ % docker exec -it a4ef1cf740d7 top /containerd.task.v2.Task/Exec is not supported: not found
I am trying to compare CPU usage of wasmedge-quickjs with nodejs.
Kindly suggest.

@ankianan - you cannot exec into a WebAssembly and run e.g. top like you're trying to in the above example. The WebAssembly is a process hosted by the runtime.
I'm not sure what types of metrics WasmEdge may serve through containerd, but I you could ask that question here: https://github.com/containerd/runwasi

You're trying to execute a program called top inside the container, but there's no such program inside your container. That's not surprising, as there's no OS inside your container, it's running a WASM file directly. (The error is saying you can't run extra processes inside the WASM container.)
I expect you can use top outside Docker to see the process usage of the wasmedge process, but you may need to set some options make make the process visible, as by default I expect top does not show processes inside containers.
docker stats might work, I'm not sure if it's hooked up for the WASM integration.


ValueError: Expecting property name

Expected Behavior
Actual Behavior
Just updated to latest dev, and now the bot won't start.
When starting the bot this happens:

[13:26:00]  PokemonGO Bot v1.0
Traceback (most recent call last):
File "pokecli.py", line 442, in
main()
File "pokecli.py", line 53, in main
config = init_config()
File "pokecli.py", line 124, in init_config
load.update(json.load(data))
File "/usr/lib/python2.7/json/init.py", line 290, in load
**kw)
File "/usr/lib/python2.7/json/init.py", line 338, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 382, in raw_decode
obj, end = self.scan_once(s, idx)
ValueError: Expecting property name: line 30 column 9 (char 666)

Here is the relevant part of the config file:
 "tasks": [
      {
        "type": "HandleSoftBan"
      },
      {
        "type": "CollectLevelUpReward"
      },
      {
        "type": "IncubateEggs",
        "config": {
          "longer_eggs_first": true
        }
      },
      {
        "type": "TransferPokemon"
      },
      {
        "type": "EvolveAll",
        "config": {
          "evolve_speed": 20,
          "use_lucky_egg": false,
          "evolve_all": "NONE",
          "evolve_cp_min": 300,
        }
      },
      {
        "type": "RecycleItems",
        "config": {
          "item_filter": {
            "Pokeball":       { "keep" : 100 },
            "Potion":         { "keep" : 10 },
            "Super Potion":   { "keep" : 20 },
            "Hyper Potion":   { "keep" : 30 },
            "Revive":         { "keep" : 30 },
            "Razz Berry":     { "keep" : 100 }
          }
        }
      },
      {
        "type": "CatchVisiblePokemon"
      },
      {
        "type": "CatchLuredPokemon"
      },
      {
        "type": "SpinFort"
      },
      {
        "type": "MoveToFort"
      },
      {
        "type": "FollowSpiral"
      },
      {
        "type": "FollowCluster",
        "config": {
            "radius": 50,
            "lured": true
        }
      },
      {
        "type": "FollowPath",
        "config": {
          "path_mode": "loop",
          "path_file": "configs/path.example.json"
        }
      }
    ],
    "max_steps": 7,
    "forts": {
      "avoid_circles": true,
      "max_circle_size": 10
    },
    "walk": 7,
    "action_wait_min": 1,
    "action_wait_max": 4,
    "debug": false,
    "test": false,
    "health_record": true,
    "location_cache": false,
    "distance_unit": "km",
    "reconnecting_timeout": 15,
    "evolve_captured": "NONE",
    "catch_randomize_reticle_factor": 1.0,
    "catch_randomize_spin_factor": 1.0,

Steps to Reproduce
Other Information
OS: Ubuntu 14.04
Git Commit: 5927c3b8a900ff79ce72fb8447c6c75dbb8ea858
Python Version: Python 2.7.6

"config": {           "evolve_speed": 20,           "use_lucky_egg": false,           "evolve_all": "NONE",           "evolve_cp_min": 300,         }
The last comma after "evolve_cp_min":300 is incorrect JSON. Try changing it to
"config": {           "evolve_speed": 20,           "use_lucky_egg": false,           "evolve_all": "NONE",           "evolve_cp_min": 300         }
You can copy paste your entire config file to https://jsonformatter.curiousconcept.com/ to see if there is any more JSON-errors.

Changed that, now I'm getting this error:

Traceback (most recent call last):
File "pokecli.py", line 442, in
main()
File "pokecli.py", line 53, in main
config = init_config()
File "pokecli.py", line 124, in init_config
load.update(json.load(data))
File "/usr/lib/python2.7/json/init.py", line 290, in load
**kw)
File "/usr/lib/python2.7/json/init.py", line 338, in loads
return _default_decoder.decode(s)
File "/usr/lib/python2.7/json/decoder.py", line 366, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/lib/python2.7/json/decoder.py", line 384, in raw_decode
raise ValueError("No JSON object could be decoded")
ValueError: No JSON object could be decoded

Nevermind, found another error in my config. Now it's working.


make tracing supported as first-class citizen

Although you could use it with tracing already, it still required the log crate as a dependency.
Not anymore :)

This came up previously in #44.  If you want to still pursue this, I would recommend creating an issue and explore the problems brought up in that PR.

Issue created for further discussion: https://github.com/clap-rs/clap-verbosity-flag/issues/121


Error in using generic ingestion

I loaded the generic json ingest_REQUIREMENT.json. Then I added instance data to ingest_REQUIREMENT.csv (the data is basically what is the HighLevelRequirement data from Turnstile but I altered the identifier name) - and this data file is attached here with "txt" extension. I was able to import the data successfully but when I queried the  ingest_REQUIREMENT.json, I got an error.
ingest_REQUIREMENT.csv.txt

This might be a clue.  I found this during random SemTK startup, NOT trying to run the query but it looks interesting.
Found this in Semtk:
Caused by: java.lang.Exception: Fuseki query returned empty response

Saw this on the Fuseki console:
Server     ERROR Exception in initialization: caught: Process ID 18268 can't open database at location C:\Users\200001934\apache-jena-fuseki-3.10.0\run\databases\fuseki_test_persistent\ because it is already locked by the process with PID 10192. TDB databases do not permit concurrent usage across JVMs so in order to prevent possible data corruption you cannot open this location from the JVM that does not own the lock for the dataset
[2021-02-05 10:42:23] WebAppContext WARN  Failed startup of context o.e.j.w.WebAppContext@5fac521d{Apache Jena Fuseki Server,/,file:///C:/Users/200001934/apache-jena-fuseki-3.10.0/webapp/,UNAVAILABLE}
org.apache.jena.assembler.exceptions.AssemblerException: caught: Process ID 18268 can't open database at location C:\Users\200001934\apache-jena-fuseki-3.10.0\run\databases\fuseki_test_persistent\ because it is already locked by the process with PID 10192. TDB databases do not permit concurrent usage across JVMs so in order to prevent possible data corruption you cannot open this location from the JVM that does not own the lock for the dataset
  doing:
    root: http://base/#tdb_dataset_readwrite with type: http://jena.hpl.hp.com/2008/tdb#DatasetTDB assembler class: class org.apache.jena.tdb.assembler.DatasetAssemblerTDB

The above error goes away when I

shut down Fuseki
remove "tdb.lck" from Fuseki's "system" folder and from each "database" subfolder
restart

I am unable to reproduce Abha's bug in a non-Docker development environment.  I will need @tuxji to help.
I think this is high priority because it is likely to be related to the problem Robert Stroud is reporting:
I have been working my way through some of the tutorial examples, but I have run into a problem - everything seems to be working until I run a query, at which point I get the unhelpful error message:

	Query failed with status: error Server response:

@cuddihyge : let me know whenever this is ready for testing.

I don't think we've made any progress on this one.  I haven't reproduced it in my dev environment yet.

@AbhaMoitra Can you list every step needed to reproduce your issue, starting from my running docker pull gehighassurance/rack-box:dev?  I don't understand the steps "loaded the generic json ingest_REQUIREMENT.json", "imported ingest_REQUIREMENT.csv", and "queried the ingest_REQUIREMENT.json" in enough detail to be able to carry them out myself.  What was supposed to happen and what error message did you get instead?  If you would rather show me visually by sharing your screen with me, you can send me a meeting invite.

@tuxji : some of the errors have now disappeared because updates by @cuddihyge . What is still giving me error is as follows

I drag ingest_AVTIVITY.json into SparqlGraph
I "run" - and that gives me the error.
Let me know if you can replicate this or we can do a call.

I meant ingest_AVTIVITY.json -> ingest_ACTIVITY.json

I have tried to reproduce this using the latest docker dev and I am not seeing an error:

OK, your issue must be your machine's resources (available memory, CPU, and/or disk).  I did the following steps and got 52 rows of results back without seeing any errors:

Ran docker pull gehighassurance/rack-box:dev
Ran docker run --detach -p 80:80 -p 12050-12092:12050-12092 gehighassurance/rack-box:dev
Waited for all services to finish starting up (viewed logs in Docker Desktop until output had stopped for a while)
Visited localhost in browser and clicked on SPARQLgraph link
Found RACK/nodegroups/ingestion/ingest_ACTIVITY.json in Windows Explorer and dragged it into sparqlGraph pane
Clicked Save button in dialog popup box
Clicked Run button
Got 52 rows and saw no errors in Docker Desktop logs pane

I see Paul had no problems too.

I am not convinced that it is a resource issue on my machine. I think it is a misalignment with the ontology. Now I am using the dev version I pulled on 2/8/2021 so you might tell me to pull a new dev version but bear with me. If you look at the screen capture that Paul has above, there are 10 properties listed within the central ACTIVITY box. One of these is "performedBy" (I know it is very hard to see the details but it is the 4th from the bottom). However when I look in the ontology, performedBy is not a property of ACTIVITY or any ancestor of ACTIVITY.
I trimmed the json (and it still gives me an error) that we talking about and showing json and ontology as follows:

Now I have no idea why I am the only one of us three who is getting the error.

@cuddihyge @tuxji : Ok here is a slightly different view that I think more clearly shows an issue. I pulled the dev branch today morning (2/11/2021) and in the following I am showing the ontology portion in SemTK.

The 2 (dangling) properties that appear after HAZARD_IDENTIFICATION are associated with ACTIVITY. I do not remember seeing this type of dangling structure before. And this relates to my previous comments. Anyway the point is that "performedBy" is not a property of ACTIVITY. You can check that in the GIT; but below is the result of searching for this property.

So, I still there is an issue. Note also that since performedBy is defined for ANALYSIS and that fragment is as follows. Note this property appears twice (once for it and once inherited from ACTIVITY).

This is a simple sorting problem in the SparqlGraph pane.  It is unrelated.   I've fixed it.

@tuxji @cuddihyge : So, with this fix, does performedBy show up as a property for ACTIVITY? I downloaded dev today (2/15) morning and I am unable to run it. I get the following error and the services do not start up.

After updating my Docker (as suggested by John) I was able to pull and run dev docker today (2/17/2021) and everything seems fine. so I am going to push this issue to "Done" as it does not involve any further changes / updates.


[windows11] I cannot run any models; whenever I try to run them, I get the error 0xc0000139.

What is the issue?
Previously, all models could run very well, but after a recent upgrade, errors are occurring. I have enabled Debug mode. What could be the issue?
[GIN] 2024/07/14 - 16:05:11 | 200 |            0s |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/07/14 - 16:05:20 | 200 |        69.6µs |       <IP_ADDRESS> | HEAD     "/"
[GIN] 2024/07/14 - 16:05:20 | 200 |     23.4842ms |       <IP_ADDRESS> | POST     "/api/show"
time=2024-07-14T16:05:21.026+08:00 level=INFO source=sched.go:701 msg="new model will fit in available VRAM in single GPU, loading" model=C:\Users\X170.ollama\models\blobs\sha256-6a0746a1ec1aef3e7ec53868f220ff6e389f6f8ef87a01d77c96807de94ca2aa gpu=GPU-06932cd6-8249-ad0c-67b5-f2bcc68be311 parallel=4 available=14287372288 required="6.2 GiB"
time=2024-07-14T16:05:21.026+08:00 level=INFO source=memory.go:309 msg="offload to cuda" layers.requested=-1 layers.model=33 layers.offload=33 layers.split="" memory.available="[13.3 GiB]" memory.required.full="6.2 GiB" memory.required.partial="6.2 GiB" memory.required.kv="1.0 GiB" memory.required.allocations="[6.2 GiB]" memory.weights.total="4.7 GiB" memory.weights.repeating="4.3 GiB" memory.weights.nonrepeating="411.0 MiB" memory.graph.full="560.0 MiB" memory.graph.partial="677.5 MiB"
time=2024-07-14T16:05:21.046+08:00 level=INFO source=server.go:383 msg="starting llama server" cmd="C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3\ollama_llama_server.exe --model C:\Users\X170\.ollama\models\blobs\sha256-6a0746a1ec1aef3e7ec53868f220ff6e389f6f8ef87a01d77c96807de94ca2aa --ctx-size 8192 --batch-size 512 --embedding --log-disable --n-gpu-layers 33 --no-mmap --parallel 4 --port 14534"
time=2024-07-14T16:05:21.050+08:00 level=INFO source=sched.go:437 msg="loaded runners" count=1
time=2024-07-14T16:05:21.050+08:00 level=INFO source=server.go:571 msg="waiting for llama runner to start responding"
time=2024-07-14T16:05:21.051+08:00 level=INFO source=server.go:612 msg="waiting for server to become available" status="llm server error"
time=2024-07-14T16:05:21.314+08:00 level=ERROR source=sched.go:443 msg="error loading llama server" error="llama runner process has terminated: exit status 0xc0000139 "
[GIN] 2024/07/14 - 16:05:21 | 500 |    354.9161ms |       <IP_ADDRESS> | POST     "/api/chat"
server.log
app.log
OS
Windows
GPU
Intel
CPU
Intel
Ollama version
0.2.5

Have you tried reinstalling? This has fixed this issue for me. I'm assuming this is an issue with upgrading and installing manually seems to fix it.
You don't need to uninstall, you just download the latest Windows release and close Ollama and just let it overwrite. (This will not change Ollama environment tables or erase models, just the core of Ollama.)

Have you tried reinstalling? This has fixed this issue for me. I'm assuming this is an issue with upgrading and installing manually seems to fix it.
You don't need to uninstall, you just download the latest Windows release and close Ollama and just let it overwrite. (This will not change Ollama environment tables or erase models, just the core of Ollama.)

I have reinstalled several times and upgraded from 0.2.1 to 0.2.4 to 0.2.5.  The same problem occurs every time

I have reinstalled several times and upgraded from 0.2.1 to 0.2.4 to 0.2.5. The same problem occurs every time

Have you updated your graphics drivers recently? It may of been an issue with that. If not, try using a version pre-0.2.x. If any Windows Updates were installed recently prior to this issue occurring, try removing them in case they caused something to go wrong.

Hi @hljhyb sorry this happened – will get this fixed.
Would it be possible for you to open the following folder:
explorer.exe C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3

Then double click on ollama_llama_server.exe? If there's an error, can you let me know it says? It might say there's a missing DLL.

Hi @hljhyb sorry this happened – will get this fixed.嗨，对不起，这发生了 - 将解决这个问题。
Would it be possible for you to run in powershell:您是否可以在 powershell 中运行：
$env:PATH="C:\Users\jmorgan\AppData\Local\Programs\Ollama\cuda;" +$env:PATH
explorer.exe C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3\ollama_llama_server.exe

and let me know what error shows并让我知道显示什么错误

INFO [wmain] build info | build=3337 commit="a8db2a9c" tid="335452" timestamp=1721003942
INFO [wmain] system info | n_threads=10 n_threads_batch=-1 system_info="AVX = 1 | AVX_VNNI = 0 | AVX2 = 0 | AVX512 = 0 | AVX512_VBMI = 0 | AVX512_VNNI = 0 | AVX512_BF16 = 0 | FMA = 0 | NEON = 0 | SVE = 0 | ARM_FMA = 0 | F16C = 0 | FP16_VA = 0 | WASM_SIMD = 0 | BLAS = 1 | SSE3 = 1 | SSSE3 = 1 | VSX = 0 | MATMUL_INT8 = 0 | LLAMAFILE = 0 | " tid="335452" timestamp=1721003942 total_threads=20
INFO [wmain] HTTP server listening | hostname="<IP_ADDRESS>" n_threads_http="19" port="8080" tid="335452" timestamp=1721003942
llama_model_load: error loading model: llama_model_loader: failed to load model from
llama_load_model_from_file: exception loading model

@hljhyb the attached logs don't seem to have debug enabled.  Can you try updating to v0.2.8 and if that doesn't clear it up, try the following so we can try to see why it's not able to start up correctly.  Quit the tray app, then run the following which will restart it with debugging enabled.
$env:OLLAMA_DEBUG="1"
& "ollama app"

Then try to load a model, and assuming it fails, share the server.log.

@dhiltgen
I did it as you said, but it still doesn't work.
server.log

I ran "sfc /scannow" and "dism /online /cleanup-image /restorehealth," and changed the CUDA version to 11.5.
But it's still the same problem. Maybe there's an issue with my operating system.
Still, thank you for your help.

I ran "sfc /scannow" and "dism /online /cleanup-image /restorehealth," and changed the CUDA version to 11.5. But it's still the same problem. Maybe there's an issue with my operating system. Still, thank you for your help.

Ah, no problem. It may be an OS issue but I'm not sure now. Can you try the latest 0.3 update to Ollama and see if that works? If not, a Windows Update assisted OS reinstallation may be needed but that's only when we exhaust all options.
If you are sure about reinstalling, you can do it by heading to "Recovery" in Settings and clicking "Reinstall now" at the "Fix problems using Windows Update" option.
This will keep all data, settings and apps but I still recommend backing up important data for an edge case where something doesn't get kept. This also requires some patience as this could take an hour or two.
I know that the reinstall idea sounds like bad advice but it's the safest way to fix this when all options have been tried with failure as a result.

I ran "sfc /scannow" and "dism /online /cleanup-image /restorehealth," and changed the CUDA version to 11.5. But it's still the same problem. Maybe there's an issue with my operating system. Still, thank you for your help.

Ah, no problem. It may be an OS issue but I'm not sure now. Can you try the latest 0.3 update to Ollama and see if that works? If not, a Windows Update assisted OS reinstallation may be needed but that's only when we exhaust all options.
If you are sure about reinstalling, you can do it by heading to "Recovery" in Settings and clicking "Reinstall now" at the "Fix problems using Windows Update" option.
This will keep all data, settings and apps but I still recommend backing up important data for an edge case where something doesn't get kept. This also requires some patience as this could take an hour or two.
I know that the reinstall idea sounds like bad advice but it's the safest way to fix this when all options have been tried with failure as a result.

I did it , but it still doesn't work. I tried using  "Recovery" in Settings  as you said, but after reinstall, I still got the same error message.

@hljhyb we might get a little more insight if you try to run the subprocess directly. Try the following:
$env:PATH="C:\Users\X170\AppData\Local\Programs\Ollama\cuda;C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3;C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners;$env:PATH"
C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3\ollama_llama_server.exe --help

The most likely explanation for this status code is a missing or incorrect DLL, and starting it manually should hopefully cause an error dialog to pop up showing what DLL(s) are the problem.

@hljhyb we might get a little more insight if you try to run the subprocess directly. Try the following:
$env:PATH="C:\Users\X170\AppData\Local\Programs\Ollama\cuda;C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3;C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners;$env:PATH"
C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3\ollama_llama_server.exe --help

The most likely explanation for this status code is a missing or incorrect DLL, and starting it manually should hopefully cause an error dialog to pop up showing what DLL(s) are the problem.

I may not have understood your method clearly. I did not receive any prompts after running these commands.

I ran "sfc /scannow" and "dism /online /cleanup-image /restorehealth," and changed the CUDA version to 11.5. But it's still the same problem. Maybe there's an issue with my operating system. Still, thank you for your help.

Ah, no problem. It may be an OS issue but I'm not sure now. Can you try the latest 0.3 update to Ollama and see if that works? If not, a Windows Update assisted OS reinstallation may be needed but that's only when we exhaust all options.
If you are sure about reinstalling, you can do it by heading to "Recovery" in Settings and clicking "Reinstall now" at the "Fix problems using Windows Update" option.
This will keep all data, settings and apps but I still recommend backing up important data for an edge case where something doesn't get kept. This also requires some patience as this could take an hour or two.
I know that the reinstall idea sounds like bad advice but it's the safest way to fix this when all options have been tried with failure as a result.

I did it , but it still doesn't work. I tried using "Recovery" in Settings as you said, but after reinstall, I still got the same error message.

I'm completely at a loss now, I don't exactly know what's happened at this point. Sorry for not being able to help. I hope your issue gets fixed sooner rather than later.
Dropping out here. Good luck to you.

@hljhyb sorry about that.  It looks like powershell hides the error dialog I was hoping would pop up.  We need to use a cmd terminal for this experiment.
set PATH=C:\Users\X170\AppData\Local\Programs\Ollama\cuda;C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3;C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners;%PATH%
C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3\ollama_llama_server.exe --help

You should get a dialog that pops up that looks something like this (most likely a different dll will be listed)

@dhiltgen

@hljhyb sorry about that. It looks like powershell hides the error dialog I was hoping would pop up. We need to use a cmd terminal for this experiment.
set PATH=C:\Users\X170\AppData\Local\Programs\Ollama\cuda;C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3;C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners;%PATH%
C:\Users\X170\AppData\Local\Programs\Ollama\ollama_runners\cuda_v11.3\ollama_llama_server.exe --help

You should get a dialog that pops up that looks something like this (most likely a different dll will be listed)

It shows a dialog like this.
The procedure entry point cublasLtGetStatusString could notbe located in the dynamic link library C:\WINDOWS\SYSTEM32\cublas64_11.dll

It should have picked up C:\Users\X170\AppData\Local\Programs\Ollama\cuda\cublas64_11.dll instead of the one in C:\Windows\System32 given the PATH we set above, so that makes me think somehow C:\Users\X170\AppData\Local\Programs\Ollama\cuda\ is missing the libraries.  Can you share what is reported with
dir C:\Users\X170\AppData\Local\Programs\Ollama\cuda\

Thanks for that information.  So our bundled DLL exists, but even though we specify our directory first in the PATH, windows is defaulting to the system installed version of CUDA v11, and your install is most likely older than 11.3.1.  Until we can figure out how to fix the search order to force our copy, you can workaround this by upgrading cuda v11 to 11.3.1 or newer, or uninstall cuda v11 if you don't have other applications that need that version.

Thanks for that information. So our bundled DLL exists, but even though we specify our directory first in the PATH, windows is defaulting to the system installed version of CUDA v11, and your install is most likely older than 11.3.1. Until we ~can figure out how to~ fix the search order to force our copy, you can workaround this by upgrading cuda v11 to 11.3.1 or newer, or uninstall cuda v11 if you don't have other applications that need that version.
Update: looks like we'll need to inject a side by side assembly into our subprocesse executables so they add a probing privatePath to search for our packaged dependencies before the system directories are searched to prevent an incompatible v11 library from accidentally getting loaded.

I've already uninstalled CUDA, but now a pop-up appears when I try to run the model, and it still doesn't work.

I wouldn't expect that dll to exist if cuda v11 has been uninstalled.  Maybe some other piece of software installed it as a dependency in the system location?
Until we get the issue fixed, you should be able to workaround this by installing cuda v11.3.1.

I wouldn't expect that dll to exist if cuda v11 has been uninstalled. Maybe some other piece of software installed it as a dependency in the system location?
Until we get the issue fixed, you should be able to workaround this by installing cuda v11.3.1.

Thank you so much! You helped me solve this problem. It seems that a previous version of CUDA copied the cublas64_11.dll version 11.10.1 file into the system directory. The earlier version of Ollama could run, but after updating, it stopped working. The CUDA version installed later didn't update this file, so every time it was called, it used the old version. I just replaced the file, and now it's working!


Initial token implementation

Checklist:

[x] Code contains relevant tests for the problem you are solving
[x] Ensure all new and existing tests pass
[x] Update any relevant READMEs and docs
[x] Submit to the develop branch instead of master

Description:
MVP for Origin token w/ ERC-20, minting, burning, pause transfers
Sorry for the size of this PR. A few things will make reviewing easier:

All of the code in contracts/test/openzeppelin-token was ported from OpenZeppelin's ERC-20 tests with minimal (< 10 lines of code) changes. So, those don't require much review.
The main token contract is contracts/contracts/token/V001/OriginToken.
The token contract code is ported from OpenZeppelin's token contract code. I grouped functions based on the OpenZeppelin contract I based the code on.
All token data is stored in EternalStorage, except owner. I didn't think it necessary to port that one state variable.
I modeled the contract directory structure after the marketplace directory structure.
When playing with contracts in Remix, it's useful to bump the gas limit to 7,000,000.
There are more tests that need to be written. I'll do most of those in separate PRs.

I'm happy to walk through the code with any reviewers as people start freeing up from the marketplace & indexer work.
I might add more tests to this PR, but I'll save further features for another PR.
Resolves #284
Resolves #295
cc @nick @tyleryasaka @DanielVF @matthewliu

I understand your nervousness @tyleryasaka, but the problem is that we do need upgradability.
It's either EternalStorage or using a delegate proxy. Because proxies delegate calls to another contract but use the storage of the proxy contract, it's vital that the implementation change its storage layout.
The OpenZeppelin AdminUpgradeabilityProxy code is evolving independently of their token code. Case in point:
https://github.com/OpenZeppelin/openzeppelin-solidity/commit/ef347ffccc1fd50b7f24b9c2d744eceef716ce16
I can't look at this diff and guarantee that the storage layout hasn't change from the prior rev.
The OpenZeppelin tests give some confidence that the behavior hasn't changed.

The prototype I sent earlier has a more basic version of EternalStorage. It was based off this code:
https://github.com/rocket-pool/rocketpool/blob/master/contracts/RocketStorage.sol

Closing in favor of using proven token code and migrating balances between old and new contracts


Issue with Bootstrap sites

I've tried to implement this on several Bootsatrap v4 and v5 websites, it breaks on all of them. The open button is chubby and the chatbox is always cutoff at the top. Using a very basic starter templete, see image for results.

Here is another example:

I don't know if my problem is also due to the use of bootstrap, but I can't get it to work properly. It doesn't allow me to select the text input form to send messages. I can hit send, but I can't send any text.


hive metadata cache of fe automatic incremental synchronization

Support automatic synchronization of metadata updates in hive metastore(hms).
Each fe node periodically obtains the hms incremental update event, parses it, and updates the cache in fe to achieve automatic synchronization. The hms interface we need to call has getNextNotification and getCurrentNotificationEventId.
A metastore event is a instance of the class org.apache.hadoop.hive.metastore.api.NotificationEvent. Metastore can be
configured, to work with listeners which are called on various DDL operations like create/alter/drop operations on database, table, partition etc. Each event has a unique incremental id and the generated events are be fetched from Metastore to get incremental updates to the metadata stored in Hive metastore using the the public API get_next_notification. These events could be generated by external metastore clients like Apache Hive or Apache Spark configured to talk with the same metastore.
We could process the events that fetched during each rotation according to the following points.

create batch event
Create a batch of events based on the partition or table. It is convenient for us to process batch event in parallel.
filter event
For some partitions that are not cached in fe, and some events that only modify transient_lastDdlTime, we ignore these
events.
merge event
For multiple alter table/ alter parititon events of a table or partition, we only process the last one.
parallel process
Because batch events are partition-level, each batch event is processed in parallel.

Note that this feature is still a work in progress and additional improvements will be done in subsequent patches.

https://github.com/StarRocks/starrocks/issues/3045

rerun starrocks_fe_unittest

run starrocks_fe_unittest


~ is shortened incorrectly when reaching it with cd ..

The paths  / and ~ are special cases for the directory shortener. They should always appear without a delimiter. This is not the case when using cd .. to enter ~:

All settings regarding the shortening in my .zshrc:
POWERLEVEL9K_SHORTEN_DIR_LENGTH=1
POWERLEVEL9K_SHORTEN_STRATEGY=Default
POWERLEVEL9K_SHORTEN_DELIMITER="…"

My delimiter of choice is the ellipsis character … instead of three dots ..., but this happens with any delimiter, even an empty one.

Wow, you're right... that is definitely broken.
This should be pretty easy to fix, and it would just be fixing the conditional to properly parse/strip the cwd in that segment logic. I'll mark this as a good beginner bug to fix in case anyone is up for it =)

I tried my hand at it, and I don't think it's that easy.
The problem is line 812 in powerlevel9k.zsh-theme:
current_path="$(print -P "%$((POWERLEVEL9K_SHORTEN_DIR_LENGTH+1))(c:$POWERLEVEL9K_SHORTEN_DELIMITER/:)%${POWERLEVEL9K_SHORTEN_DIR_LENGTH}c")"

For this particular case, you can test it in a shortened version like so:
print -P "%2(c:…/:)%1c"

And this will reliably fail the exact same way:
> cd && print -P "%2(c:…/:)%1c"
~
> cd work/.. && print -P "%2(c:…/:)%1c"
…/~

I have a really hard time understanding how this statement works exactly, but I see if I can find out. This document seems to be a good source.

Ok this is definitely a bug in zsh. (I'm running version 5.0.2)
It comes down to the conditional expression not evaluating the way it should (I replaced the c with a ~ and moved the 2 inside here because it's clearer to me):
> cd && print -P "%(2~:true:false)"
false
> cd work/.. && print -P "%(2~:true:false)"
true

This is a super-specific bug, because it only works if the argument 2. As soon as it's three (so as soon as your POWERLEVEL9K_SHORTEN_DIR_LENGTH is 2 or higher), it also returns false as it should.
Now to find out how to report bugs on zsh...

Reporting ZSH issues here.
https://github.com/robbyrussell/oh-my-zsh/issues

That's just the oh-my-zsh configuration framework. Bugs of zsh itself need to be reported via the mailing list as I found out. I already did that, and the bug has been confirmed, so it will hopefully be fixed in a future release.
I guess this issue here can be closed now.

It would be great to tag the zsh issue here if you can find it on github.

Zsh doesn't have an issue tracker on github, unfortunately, and their bug tracker on sourceforge is inactive.
They do have a mailing list archive, however. You can see the current state of the thread here.

@bhilburn - this can be closed since it is a ZSH issue, not a 9k issue.

This is already fixed via #773


website domain choice

https://www.godaddy.com/domainsearch/find?checkAvail=1&tmskey=&domainToCheck=growfast
we might want to go for the growfast.io

There's also this:
http://www.freenom.com/en/index.html
Free second-level domains for a year. May be interesting for the beginning.


Startup errors

Sorry, I don't know anything about python :(
When running deepLuna.py through IDDLE Shell, errors appear
Also opens a blank window with the name Welcome to deepLuna
Python 3.11.2 (tags/v3.11.2:878ead1, Feb  7 2023, 16:38:35) [MSC v.1934 64 bit (AMD64)] on win32
Type "help", "copyright", "credits" or "license()" for more information.
=========== RESTART: C:\Users\User\Desktop\deepLuna-main\deepLuna.py ===========
Traceback (most recent call last):
File "C:\Users\User\Desktop\deepLuna-main\deepLuna.py", line 8, in
main()
File "C:\Users\User\Desktop\deepLuna-main\deepLuna.py", line 5, in main
StartWindow().mainloop()
File "C:\Users\User\Desktop\deepLuna-main\luna\ui\start_window.py", line 30, in init
icon = Image.open("icone.png").resize((140, 140))
File "C:\Users\User\AppData\Local\Programs\Python\Python311\Lib\site-packages\PIL\Image.py", line 3218, in open
fp = builtins.open(filename, "rb")
FileNotFoundError: [Errno 2] No such file or directory: 'icone.png'

This is now fixed, but I'd recommend using the command line tools and raw script format over the UI, since they're what we actually used internally / are more fleshed out than the UI at this point.


Player is stuck at BUFFERING state after a short period of time

Version
Media3 1.4.1
More version details
No response
Devices that reproduce the issue
Samsung SM-G9750, Android 10
Devices that do not reproduce the issue
No response
Reproducible in the demo app?
Yes
Reproduction steps
1.add a audio item in "media.exolist.json" file, like this：

This URL is valid for 2 hours. If you are fixing this bug, you can contact me and send you the latest link.
2.run the demo, then select the audio address you just added
3.Wait for it to play for a while, about 2-4 minutes, and then it will get stuck at BUFFERING.
this is my log.
log001.log
Expected result
The media plays successfully
Actual result
Player is stuck at BUFFERING state
Media
I don't want to post media publicly, I will send my media to your email.
Bug Report

[X] You will email the zip file produced by adb bugreport to<EMAIL_ADDRESS>after filing this issue.

I have sent the latest media url to<EMAIL_ADDRESS>


Feature/daef 251 autocomplete input control

>>> RETARGETED TO MASTER FROM PR #516 <<<
This PR introduces autocomplete input control.

@DominikGuzei is this PR ready to be merged? Or is it still in WIP? :)


(#5442) fetch should also resolve canonical URL references

I tried to follow the existing pattern, I'm open to any suggestions to make this less ugly

Please also add a changelog


SwiftReflectionTest: add dependency on Glibc module on FreeBSD

I double-checked all of the other Test/Unittest modules, too.

Thanks—would you mind kicking off tests for me?