diff --git a/community/2026-06-10-community-meeting-transcript.mdx b/community/2026-06-10-community-meeting-transcript.mdx new file mode 100644 index 00000000..de05e5b3 --- /dev/null +++ b/community/2026-06-10-community-meeting-transcript.mdx @@ -0,0 +1,217 @@ +--- +date: '2026-06-10' +title: 'Transcript: Wasm Autoscaling on Kubernetes, wasmCloud 2.3.0, and the WASI Preview 3 Vote' +description: 'Full transcript of the June 10, 2026 wasmCloud community call covering Wasm runtime autoscaling on Kubernetes with KEDA, the 2.3.0 release, multi-subscription workloads, and the WASI P3 launch vote.' +keywords: + - wasmcloud + - webassembly + - wasm component model + - wasm runtime autoscaling + - webassembly kubernetes + - wasi p3 + - wasi preview 3 + - kubernetes hpa + - nats kubernetes + - helm wasmcloud + - webassembly news +image: https://i.ytimg.com/vi/v0o4ptC_jqQ/maxresdefault.jpg +showTitle: true +slug: 2026-06-10-community-meeting-transcript +speakers: + - jeremy-fleitz + - bailey-hayes + - eric-gregory + - aditya +about: wasmCloud +mentions: + - Kubernetes + - WASIPreview3 + - Wasmtime + - NATS + - JCO + - ComponentModel + - wash + - runtimeOperator +--- + +import YouTube from 'react-player/youtube'; + +**[← Back to watch page](/community/2026-06-10-community-meeting/)** + + + +
+ + Watch on YouTube ↗ + +
+ +*wasmCloud Weekly Community Call — Wed, Jun 10, 2026 · 27 minutes* + +{/* Speakers: Jeremy Fleitz, Bailey Hayes, Eric Gregory, Aditya Salunkhe */} + +--- + +{/* truncate */} + +## Transcript + +**Jeremy Fleitz** [0:12](https://youtu.be/v0o4ptC_jqQ?t=12) + +Okay, welcome to the weekly wasmCloud community call, June 10. Today we've got quite a few things on our agenda. Let me just share my screen. This will be posted later today, but I know GitHub's having a couple issues — looks like now it's just API authentication issues. + +So today we're going to be going through — I'm going to be showing off **auto-scaling workloads**. This closes out one of the open issues in our project roadmap. Then we'll cover some additional **Helm enhancements**, really just for additional knobs, especially if you want to further dictate how wasmCloud is installed — including if you're using your own custom host. And then Bailey is going to be showing off something she's been working on with **workloads with multiple subscriptions and handlers**, and we'll also be doing our documentation of the week. + +So to start off with the first one — with auto-scaling workloads — this was opened up inside our project roadmap for this current quarter, and I was trying to get this across the line. It's really, really close, and I have a demo just showing off exactly how this all works. What this does, for the **workload deployment CRD** that we use inside Kubernetes to schedule a workload to a host, this adds now the **`/scale` subresource**, which allows for basically the **Horizontal Pod Autoscaler** in Kubernetes to work with our workload deployment. It works based on using that subresource, and it sets up the replica path and the label selector path. + +Now, HPA literally stands for *Horizontal Pod Autoscaler*. Since we're not really scheduling per pod for a workload component — because that would just completely defeat part of the purpose of getting high density — each host is still just a single pod. We don't want to scale the actual host pods, we want to scale the actual workload deployments. + +**Eric Gregory** [2:25](https://youtu.be/v0o4ptC_jqQ?t=145) + +Colin, I don't think you're on mute there, but I just — + +**Jeremy Fleitz** [2:28](https://youtu.be/v0o4ptC_jqQ?t=148) + +Mute him. Yeah, yeah. + +So, anyways, this PR is what adds that, and just to show off exactly how this all works: I have a test demo script that I'm going to be uploading into our public **Cosmonic Labs** section, so you can use this against wasmCloud as well. The first thing you do is set up your Kind cluster, just following the documentation that's up on wasmCloud Docs, and then you install **Prometheus** and **KEDA** (Kubernetes event-driven autoscaling — that is also a CNCF addition to Kubernetes). That allows you to take KEDA to point at Prometheus and take an external metric for controlling the Horizontal Pod Autoscaler CRD. + +Now, what this demo does — I did not want to add any more complexity to it. Typically, what you would do in this case is have this actually talking to your ingress to measure backpressure, to see if responses are taking too long. What I actually did instead is, inside the workload, I'm just deploying the typical Hello wasmCloud workload component, and the target metric is just a simple gauge metric coming across, saying "I want to always keep 10 requests per instance out there." So my local script makes about 450 requests a second. What I expect is at first you just see one instance handling all 450 requests, but then over time it's going to keep scaling up to roughly 46 workload deployments at 10 requests per second, so it should still equal about 460 coming in. + +So, going back to the setup here, I do have Prometheus and KEDA installed, just by the Helm charts. I also configured **OTel** to use **.NET Aspire** as well, just for a quick dashboard to show how it is routing inside the workload components. As far as deploying wasmCloud, I followed the same steps but I did override some values in the host group section — this was really just adding `meters enabled`, so that's going to allow for each HTTP invocation to be reported back to the OTel collector endpoint. That's going to report every five seconds, so there's going to be a little bit of delay coming around. + +As far as the KEDA side of things on the KEDA CRD: I said go ahead and make it so you can have up to 1,000 workload components deployed. The minimum should be one. It is the Hello World workload deployment, and then just to add some stabilization — so it's not constantly updating the workload deployment over and over again — I said go ahead and update it every 10 seconds, just to give time for the whole reconciliation process to come around. + +So, already got all this stuff configured, and I have a load script here that I'm going to run. This is just going to start calling out to `localhost` and constantly pinging that kubectl — I'm sorry, that Kind cluster locally. And since the Kind cluster followed the wasmCloud deployment steps, that's just simply port 80 going straight to the manifest. So if I look at my workload deployment here, this is the Hello World application. If you notice, this is taking any ingress coming in from the Kubernetes Service called `hello-world`. If I look at that, this has all the **Endpoint Slices** registered to all three hosts, because it's already spun up to at least three instances spread across all the hosts. This is where it ties NodePort `3950` to the target port `80` on the host. Port `3950` on the wasmCloud standard Kind default install already has a local port-forward to it, so that's why I can just say `curl localhost` and it routes automatically. + +**Jeremy Fleitz** [7:09](https://youtu.be/v0o4ptC_jqQ?t=429) + +So now, if I look at my hosts here, these are all three hosts I have running right now. I can go inside each one and I can see this one already has 12 of the instances. There's no other wasm components running other than this test. This one right here has 10, so I've got 22, and got seven, so that's 29. If I look at my watch here, it has now a total of 38. If I were to take these two numbers, I'm going to get close to 460 transactions a second. As long as this is right around 10, it's not going to try to scale up anymore. + +I'm hoping that it might… we might say, change a little bit there, but while that's still going I'm just going to bring up the Aspire metrics here and just show how this is all routing. + +Now, I did restart my host a few times, and so I got — I probably should have cleared this out before the demo, but three of these are going to have actual metrics coming across. If I do the total count here, this host right here, the total number of replicas of the host components on this one, is doing roughly 255,000 requests, and this one over here is close — not the same — but if I look at the overall, what I've processed so far is 707,063. + +So I'm just going to go back here to see where we're at, and we're still just hanging on at 38. I'm just going to go ahead and kill this load process here. Actually, it looks like I've already saw it go down to 35 just by automatically doing that. Just wait a moment here. Yep. Since I started taking the load off, it's going to start degrading the number of replicas down. Once again, I have every five seconds to report the metrics, and then every 10 seconds for it to actually update the workload deployment. + +So this is really just showing true **workload horizontal autoscaling, not pod autoscaling**. Once again, you would normally put this against your ingress for backpressure, not really in this type of case. So I will pause if anybody has any questions on this. Okay, I don't think I see anybody's hands. Oh, yeah — all right, awesome. + +Okay, so going on to the next thing: **Helm enhancements**. This is something that Bailey and I and the team were talking about, and this also came up from Mike on our wasmCloud Slack channel yesterday. He ran into an issue with using it — I think **Synadia**, thank you. He's using that, which is a distributed NATS cluster, and he was asking, "How can I set NATS inside wasmCloud to point to Synadia versus the installed NATS instance?" And yes, you can do that, but it's actually kind of hard. It doesn't make sense to. + +I mean, you can use Kustomize, but the way you use Kustomize is you set up an external service inside Kubernetes that would basically route to the thing of the same name, so you're not changing the hard-coded name our Helm chart is looking at. So this really triggered: okay, what all do we want to make configurable inside the Helm chart? And it's really everything. Anything that's hard-coded should be a default value — that's our opinionated install — but if you do have a cluster you're deploying into, especially if you're self-hosting your NATS install (maybe you have a NATS team focused on the health of NATS), then yes, you should be able to use that. + +**Jeremy Fleitz** [11:36](https://youtu.be/v0o4ptC_jqQ?t=696) + +The other thing we came up with: there are times you actually might want to have a **control-plane / scheduler NATS URL** — just for communicating between the host and the runtime operators — as well as a separate NATS installation for just your workload components to talk on. That way you don't have any cross-talk on subjects and things like that that might happen. So that's why we're adding even another NATS configuration as well. + +There's also the ability to bring in your own **environment variables**, as well as passing additional arguments into the actual containers being deployed. The argument side makes a lot of sense for if you bring your own custom host — there might be times where you have the default host out of the box but you do want to add a, well, not using the host plugin component plugin (that's coming up as a feature) — maybe you want to compile it all together. You might have some additional arguments you also want to pass. So this is going to be coming up shortly in one of the next releases. + +Any questions for everybody on the call? I need to do better looking at the… + +**Bailey Hayes** [12:57](https://youtu.be/v0o4ptC_jqQ?t=777) + +Oh, you're doing great. Our next scheduled release for folks wondering is Tuesday? + +**Jeremy Fleitz** [13:04](https://youtu.be/v0o4ptC_jqQ?t=784) + +Yes. Thank you. All right, so those were the two things I wanted to cover at first. I'm just going to hand it over to Bailey. + +**Bailey Hayes** [13:14](https://youtu.be/v0o4ptC_jqQ?t=794) + +Yeah, okay. So you just actually showed the data NATS URL field that we pass into Kubernetes, and one of the changes that I did is reflecting that essentially into what we run when we run `wash dev` — when we run a `wash dev` host. + +So a couple of different changes, but basically two larger PRs that have landed on `main` now, so I'm going to demo this straight off of `main`. Let's look at the configuration first. So I'm building one component, and this is basically my HTTP handler. So the main endpoint, when I hit my localhost, this is the first component that we'll hit, but I'm also running a multi-component… + +**Aditya Salunkhe** [14:00](https://youtu.be/v0o4ptC_jqQ?t=840) + +I already have two built-ins. Sorry. + +**Bailey Hayes** [14:05](https://youtu.be/v0o4ptC_jqQ?t=845) + +Hey — + +**Aditya Salunkhe** [14:07](https://youtu.be/v0o4ptC_jqQ?t=847) + +My bad. + +**Bailey Hayes** [14:08](https://youtu.be/v0o4ptC_jqQ?t=848) + +Sorry, it's good to see you. Okay, so if we're running with other components inside our workload, this top-level component is going to route to these others — to both `task-leet` and `task-reverse`. This is a template that we had already provided, but it didn't allow you to do **multiple subscriptions**, and there's a couple of reasons why. + +Reason number one is that we didn't have any **configuration affordance** for you to be able to do that. What I mean by that is we didn't have a way for us on a **per-component level** to be able to say: I have my own configuration. And I wanted to say `subscriptions: ...`, so this one is going to subscribe to the `task.leet` topic, and this one's going to subscribe to the `task.reverse` topic. + +If we look at the architecture: we have a client, we're going to hit our HTTP API, and then this is actually going to post to our message broker. Off of those subscriptions, depending on the subscription topic, either it'll go to `task-leet` or it'll go to `task-reverse`. + +I'm just going to run that over here, open up a couple, and we'll say `wash dev`. Open it up — and then here's our little task API. One thing I added to this template is that I also expanded out the UI that we bundle in, mainly because I actually showed my partner this demo, and she was like, "this is pretty lame." And I was like, actually, the cool part is *this*. This is the cool part. + +But yeah, okay, I'll run the demo. We're first going to do **leet speak**. So I type something like this and I get this type of leet-speak back. If I change it to reverse and send a task — I didn't come up with a unique other task other than just reversing the words. So this demo now has the second component in it, and it reverses the words. It also has this little prefix; I don't know if you noticed that when I switched to leet speak it pretends to be a robot. When I switched to reverse, it shows me that I'm actually doing a little reverse. That actually is coming from inside the component. + +So, anyways, now we've got this little architecture view. I hope we can use this pattern continuing forward on our examples and templates, where if it's not the coolest of demos, at least have the architecture on the UI page so people understand what you're trying to highlight to them, and why we think it's interesting. + +So essentially we now support being able to pass in **local environment variables** and **local config on a per-component basis** inside our dev configuration — so for your local dev. Another key point of what we had to change to make all of this work: if you go into `target/release`, here's my Wasm, and if I do `wasm-tools` — let's look at the reverse WIT. You'll see that it's a consumer (so it's pulling in consumer types), but most importantly, it's a **handler** — so it's exporting being able to handle these messages. + +**Bailey Hayes** [17:34](https://youtu.be/v0o4ptC_jqQ?t=1054) + +If we look at our HTTP API for how it does that, basically it's just posting based on whatever that `task` is. It's going to say, go to that subject that I'm configured to go to. So it isn't directly linked per se to those components — they're all picking it up off of the message broker. + +If I go to `task-leet`, for example — here you'll see that it's subscribed, and then it does its little leet-speak. But the main point here is that this is its one export. Here's the trick: this is its one export, but also look at this one — oh no, it has the *exact same export*. + +That was the challenge that we ran into. Previously we were trying to prevent cycles. So whenever we ran — I'll do a bad job saying things while doing two things at once — whenever we were instantiating a workload, we were looking for cycles where it was like, "oh, we've got duplicate exports, so that's going to be ambiguous for us to be able to do intercomponent linking." But it's actually not ambiguous if other components inside the workload aren't trying to **import** that export. So you don't have a cycle there. + +That landed as part of this change right here. So basically now we say, all right, when we're linking up our components, we still have a check on the **import**. So let's say I have components A, B, and C, and component A says "I want to import messaging handler" — that export I showed earlier — but then both B and C both export messaging handler. That would be an ambiguous import and will fail at runtime. The solution for somebody who runs into that would be to either compose their components together by being careful about which instance you actually want to link to (and do that with `wac`), or put it in a different component workload entirely — decouple those from the workload deployment. + +It's not a problem if each one of these components all have the same export, because the host knows which component instance it wants to call when it's doing that routing. Another aspect of the change here is we made it so that the **in-memory messaging plugin** knows how to do that sort of subject routing. So I did that with in-memory. One other thing is that if I had specified a data NATS URL like what Jeremy just demoed for the Kubernetes side, then it would have actually automatically loaded the **NATS plugin**, and in that scenario I would have also needed to run NATS locally. So we default still to the in-memory version for local development to make it easier — people don't have to bring their own infrastructure to get things working. But if they want, they can also use our NATS plugin to do this as well. + +So I think that is sort of the roundup of some of those big changes that landed. Questions? + +Oh, yeah, and I did it for **TypeScript** too. If we go over to the TypeScript repo, you'll see basically the exact same template name, and with the exact same HTML essentially in it. When you run it, you can't even tell that you're running TypeScript components versus Rust components. We could probably, if we really wanted to, even do an interchange where one `task` worker is Rust and the other is TypeScript, and vice versa. But right now we just have all the Rust or all the TypeScript versions, and I'll post that PR in the chat. I think that's it for me, unless folks have questions. + +**Jeremy Fleitz** [21:48](https://youtu.be/v0o4ptC_jqQ?t=1308) + +All right, awesome. So now we have our documentation side. Eric, do you want me to go over that, or do you want to present? + +**Eric Gregory** [21:58](https://youtu.be/v0o4ptC_jqQ?t=1318) + +Maybe if you've got the agenda, maybe go ahead. + +**Jeremy Fleitz** [22:03](https://youtu.be/v0o4ptC_jqQ?t=1323) + +Absolutely. Okay, so there's two things we wanted to present to everybody. First off is our **2.3.0 release** that literally came out last week. It just adds several new enhancements to wasmCloud. It does have some additional fixes to the OTel support, as well as how to do workload environment config and secrets inside the `wash` config YAML for `wash dev`, so please check this out inside our blog. + +One other thing to call out: it does have a `loud` host now in there too, especially inside the examples. So this is a good way to show, even from an egress side, that from a workload component you're able to control what data is passed and where. + +The other thing we wanted to call out is we have some updated documentation on our **ingress**. This is really useful — once again, just looking at our wasmCloud Slack, with the change from going from the runtime gateway (that's now deprecated) to being more **Kubernetes-native** by using Services and Endpoints. This really just goes into an overall architecture on how you can configure it: first into an Ingress, which then goes to Service / kube-proxy, looks at the Service as well as the **Endpoint Slices** registered (like I showed inside the demo), and then that's how it's going to know which IP address to pass to the host pod. The host will then inspect what the header is coming in, as well as the request coming in, to figure out which WebAssembly component the whole thing gets routed to. So this section right here, underneath the operator manual, is very useful for explaining how everything now works the 2.3.0 way, after the runtime gateway. + +The last thing to call out — and it's very, very important — was the **WASI P3 vote is tomorrow**. Bailey, I'm not sure if you want to add anything more to this or not. + +**Bailey Hayes** [24:21](https://youtu.be/v0o4ptC_jqQ?t=1461) + +Guess what folks, we're almost there. It's very exciting. It's very nerve-wracking. + +Eric has a really great PR up on `wasi.dev` that's in review — kind of doing the refresh from everything around **WASI Preview 3**, calling out the **WASI test suite**. + +Victor, along with Tomas, has successfully gotten test suite compliance for **JCO**. So you can go and pull off `main` of the WASI test suite, which is in the WebAssembly repo, and run that — and you can see that **JCO is compliant**. That makes it the second reference implementation. **Wasmtime** was already compliant, and so with two reference implementations, and so long as we have full consensus tomorrow, we will be launching. + +What does that mean for us? We're going to enable **WASI P3 by default** pretty soon after that. Alex is going to go and enable the **component model async feature flags** by default over in Wasmtime. It won't be — I don't think it'll be in Wasmtime 46. The latest release is Wasmtime 45; 46 has already branched off and is undergoing continuous fuzzing. But **Wasmtime 47**, I believe, will be the one that will have all this enabled by default, and aiming to also bundle in the WIT interfaces from **WASI 0.3.0**. + +So, once we vote, we say we want it. I will create a release that creates OCI artifacts with WASI 0.3.0 inside it. So there's going to be some automation glue spreading out after we launch, but that is the go-ahead for everybody to begin integrating and embedding and enabling it by default. So, yay! Exciting — + +**Jeremy Fleitz** [26:15](https://youtu.be/v0o4ptC_jqQ?t=1575) + +— times. + +**Bailey Hayes** [26:16](https://youtu.be/v0o4ptC_jqQ?t=1576) + +Any questions on that? Oh — oh, yeah, **Aditya**, I've been playing with your PR. It's great. Nice work, man. + +You're working on being able to share values basically inside the same store. You and I are talking about what it would look like with multiple stores. I've got thoughts there. We need to talk through that at some point, but maybe — maybe not today. It's a little confusing, but maybe if you get a chance to read some of the docs that I sent you, then we can dive into it together next time. Cool. + +**Jeremy Fleitz** [27:00](https://youtu.be/v0o4ptC_jqQ?t=1620) + +Okay, I think that is everything on the agenda. So, opening up to the floor if anybody has any other things to discuss. + +All right, and if not, then happy wasmCloud Wednesday, and we will catch you all next week. All right. Thanks, everybody. And if there's anything else prior to that, hit up our wasmCloud Slack group. + +**Bailey Hayes** [27:30](https://youtu.be/v0o4ptC_jqQ?t=1650) + +Thanks, folks. Bye bye. diff --git a/community/2026-06-10-community-meeting.mdx b/community/2026-06-10-community-meeting.mdx index f296eb21..73aabd19 100644 --- a/community/2026-06-10-community-meeting.mdx +++ b/community/2026-06-10-community-meeting.mdx @@ -1,59 +1,170 @@ --- date: '2026-06-10' -title: 'Meeting Agenda - 2026-06-10' +title: 'Wasm Autoscaling on Kubernetes, wasmCloud 2.3.0, and the WASI Preview 3 Vote' +description: 'wasmCloud community call on horizontal pod autoscaling for Wasm workloads with KEDA, the 2.3.0 release, Kubernetes-native ingress, and the WASI P3 launch vote.' +keywords: + - wasmcloud + - webassembly + - wasm component model + - wasm runtime autoscaling + - webassembly kubernetes + - wasi p3 + - wasi preview 3 + - kubernetes hpa + - nats kubernetes + - helm wasmcloud + - webassembly news +chapters: + - { seconds: 12, label: "Welcome and the auto-scaling workloads demo" } + - { seconds: 429, label: "Watching the workload scale to 38 instances and 460 req/s" } + - { seconds: 696, label: "Helm chart enhancements: pluggable NATS and custom hosts" } + - { seconds: 794, label: "Multi-subscription workloads with wash dev" } + - { seconds: 1054, label: "Removing the duplicate-export cycle check" } + - { seconds: 1323, label: "wasmCloud 2.3.0 release and Kubernetes-native ingress" } + - { seconds: 1461, label: "WASI P3 vote and Wasmtime 47" } + - { seconds: 1620, label: "Wrap-up and open floor" } +image: https://i.ytimg.com/vi/v0o4ptC_jqQ/maxresdefault.jpg +duration: 1654 +showTitle: true +slug: 2026-06-10-community-meeting +speakers: + - jeremy-fleitz + - bailey-hayes + - eric-gregory + - aditya +about: wasmCloud +mentions: + - Kubernetes + - WASIPreview3 + - Wasmtime + - NATS + - JCO + - ComponentModel + - wash + - runtimeOperator --- -## Agenda +import YouTube from 'react-player/youtube'; -{/* Update before the start of the meeting with planned agenda items */} +{/* Video hero — the whole point of this page */} -- @jfleitz auto-scaling workloads https://github.com/wasmCloud/wasmCloud/pull/5244 -- @jfleitz [helm enhancements](https://github.com/wasmCloud/wasmCloud/issues/5245) -- @ricochet [workloads with multiple subscriptions/handlers](https://github.com/wasmCloud/wasmCloud/pull/5243) + + +
+ + Watch on YouTube ↗ + +
+ +The June 10, 2026 wasmCloud community call demonstrates **Wasm runtime autoscaling on Kubernetes**. Jeremy Fleitz scales a single Wasm workload from one instance to 38 at roughly 460 requests per second using **KEDA** and the standard **HPA scale subresource** on the workload deployment CRD, then Bailey Hayes demos **multi-subscription workloads with `wash dev`**, letting one workload host multiple components subscribed to distinct NATS topics with per-component config. The team discusses **wasmCloud 2.3.0** with Helm-configurable NATS, a Kubernetes-native ingress story, and a new egress-control example, and looks forward to the ** launch vote** scheduled for the following day, with JCO joining Wasmtime as the second reference implementation. {/* truncate */} +## Key Takeaways + +- **Wasm horizontal pod autoscaling on Kubernetes lands** — the workload deployment CRD now exposes the standard `/scale` subresource, so the [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/) and [KEDA](https://keda.sh/) can drive replica count off any Prometheus metric, including request volume +- **A 460 req/s demo scales the Hello World workload from 1 to 38 instances** — KEDA polls an OTel-emitted invocation gauge, targets 10 req/s per instance, and reconciles the workload deployment every 10 seconds without disturbing the host pods +- **Workload-level scaling preserves wasmCloud's high-density story** — host pods stay fixed per node while the scale subresource adds and removes Wasm component instances inside them, the opposite of one-pod-per-workload container scheduling +- **Helm chart enhancements expose every hard-coded NATS knob** — separate control-plane and data-plane NATS URLs, BYO NATS for [Synadia](https://www.synadia.com/) or external clusters, plus arbitrary container args and environment variables for custom-host images +- **`wash dev` now supports multiple components and per-component config** — one workload can run an HTTP front-end plus several messaging handlers, each with its own `subscriptions` config (`task.leet`, `task.reverse`) and per-component environment variables +- **The runtime's intercomponent-linking cycle check was relaxed** — duplicate exports across sibling components are no longer flagged as ambiguous when no other component in the workload imports that export, unlocking multi-handler workloads in a single `wash dev` session for both Rust and TypeScript templates +- **wasmCloud 2.3.0 shipped last week** with workload env config and secrets in [`wash` config YAML](/docs/wash/), OTel fixes, a new `loud` example host demonstrating egress control from workload components, and updated [Kubernetes-native ingress](/docs/kubernetes-operator/operator-manual/overview/) docs replacing the deprecated runtime gateway +- **The WASI P3 launch vote is tomorrow** — JCO is now the second reference implementation alongside Wasmtime; on a pass, wasmCloud will enable [WASI P3](/blog/wasi-p3-on-wasmcloud/) by default, the component-model async feature flags land in Wasmtime 47, and OCI artifacts will bundle the WIT interfaces from WASI 0.3.0 + +## Chapters + +- [0:12 — Welcome and the auto-scaling workloads demo](https://youtu.be/v0o4ptC_jqQ?t=12) +- [7:09 — Watching the workload scale to 38 instances and 460 req/s](https://youtu.be/v0o4ptC_jqQ?t=429) +- [11:36 — Helm chart enhancements: pluggable NATS and custom hosts](https://youtu.be/v0o4ptC_jqQ?t=696) +- [13:14 — Multi-subscription workloads with wash dev](https://youtu.be/v0o4ptC_jqQ?t=794) +- [17:34 — Removing the duplicate-export cycle check](https://youtu.be/v0o4ptC_jqQ?t=1054) +- [22:03 — wasmCloud 2.3.0 release and Kubernetes-native ingress](https://youtu.be/v0o4ptC_jqQ?t=1323) +- [24:21 — WASI P3 vote and Wasmtime 47](https://youtu.be/v0o4ptC_jqQ?t=1461) +- [27:00 — Wrap-up and open floor](https://youtu.be/v0o4ptC_jqQ?t=1620) + ## Meeting Notes -{/* Add summary of topics during the meeting. Each Topic should have an H3 heading. A list is usually sufficient for the recap */} +### Auto-Scaling Wasm Workloads on Kubernetes -### Topic 1 +Jeremy Fleitz opened the call with the [autoscaling PR](https://github.com/wasmCloud/wasmCloud/pull/5244) that closes one of the Q2 roadmap items: bringing **Wasm runtime autoscaling** to Kubernetes through the standard Horizontal Pod Autoscaler contract. The change adds the `/scale` subresource to the workload deployment CRD that the [wasmCloud runtime operator](/docs/kubernetes-operator/) uses to schedule a Wasm workload onto a host. With that subresource in place (replica path plus label selector) HPA (and the broader CNCF [KEDA](https://keda.sh/) project, which lets HPA target any external metric source like Prometheus) can scale the workload exactly the way it scales a Deployment. -- Note 1 -- Note 2 +The architectural point Jeremy emphasised is that **the host pod count stays fixed**. Containers scale by adding pods because each container is its own scheduling unit. wasmCloud hosts intentionally pack many Wasm component instances into one host pod per node — that is most of the density story. So the scale subresource here adds and removes **workload instances inside the existing host pods**, not host pods. HPA literally stands for *horizontal pod* autoscaling, but the wasmCloud workload deployment CRD reuses that contract to scale workload components, which is the unit the platform actually cares about. -### Topic 2 +The demo ran the stock Hello World workload component on a Kind cluster following the [operator quickstart](/docs/kubernetes-operator/), with [Prometheus](https://prometheus.io/) and [KEDA](https://keda.sh/) installed via their Helm charts and [.NET Aspire](https://learn.microsoft.com/en-us/dotnet/aspire/) running as the OTel dashboard. KEDA was pointed at a workload-emitted Prometheus gauge with a target of 10 requests per second per instance; a local script then drove ~450 requests per second at `localhost`, which the Kind port-forward routed through the Kubernetes Service into the host pods. Within seconds the workload scaled out — Jeremy watched three hosts pick up 12, 10, and 7 instances on the way to a stable 38 instances handling close to 460 req/s. KEDA reports the OTel gauge every five seconds, the operator updates the deployment every ten, and a stabilization window keeps the controller from flapping. The test script and a runnable harness will land in the public Cosmonic Labs repo so anyone can replay this on their own cluster. -- Note 1 -- Note 2 +The natural production shape is to target an **ingress back-pressure metric** rather than a self-reported request gauge: scale on rising request latency or queue depth, not on the workloads' own report of how busy they are. The demo used the simpler signal so the scaling behaviour was easy to read off the dashboard. -## Weekly highlights +### Helm Chart Enhancements: Bring Your Own NATS and Custom Host -### Issue of the Week +The second item came directly out of [Mike's question](https://github.com/wasmCloud/wasmCloud/issues/5245) on the wasmCloud Slack about pointing wasmCloud at a [Synadia](https://www.synadia.com/) cluster instead of the NATS instance the chart installs by default. The current escape hatch is a Kustomize external-service rewrite: workable, but ugly enough that it really should not be the answer. So Jeremy and Bailey reviewed the chart with a "anything hard-coded should be a default value, not a permanent value" lens and opened up the rest of the surface. -- [title](https://github.com/wasmcloud/wasmcloud/issues/) +The new knobs land soon: a **data-plane NATS URL** that workload components talk on, distinct from a **control-plane / scheduler NATS URL** that the host and runtime operator use for orchestration — so you can isolate subjects, run different NATS topologies for each, or point one side at Synadia and keep the in-cluster NATS for the other. The chart also accepts **arbitrary environment variables** and **extra container args** passed through to the host containers, which mostly matters when you are running a **custom-built host image**: a pre-host-plugin world where you compile in your extensions and need to flip a flag at start time. Host component plugins are coming separately, but the args path is the bridge for now. The whole set targets the next release. -### Documentation of the Week +### Multi-Subscription Workloads with `wash dev` -- [v2.3.0 release blog](https://wasmcloud.com/blog/wasmcloud-2-3-0-release/) -- [ingress to component in k8s](https://wasmcloud.com/docs/kubernetes-operator/operator-manual/overview/#architecture) +Bailey Hayes then demoed the matching developer-experience side — the [multi-subscription PR](https://github.com/wasmCloud/wasmCloud/pull/5243) that lets a single workload run several components with **per-component config**, each subscribed to a different message topic. The demo workload had an HTTP front-end (a small UI plus a `task` API) plus two messaging handlers behind it: `task-leet` (l33t-speak the input) and `task-reverse` (reverse the words). The front-end posts to `task.leet` or `task.reverse` on the in-memory message broker; each handler component declares its own subscription in its dev config; the host routes each subject to the matching component instance. Bailey also expanded the bundled UI template to include a small **architecture diagram** so demo viewers can see the shape of the workload at a glance — a pattern she wants to standardize across the templates. -## Community Updates +Two configuration pieces unblock this. First, **`wash dev` now reads per-component config** — a workload can declare `subscriptions: [...]` (and other config) at the component level instead of only at the workload level. Second, **local environment variables now flow into a component's runtime context** — the same `${VAR}` flow that landed for env in 2.3.0 now reaches per-component config. The template is mirrored across Rust and TypeScript repos with the same HTML and the same component contract, so language choice is transparent to the user. -### Tune in… +### Removing the Duplicate-Export Cycle Check -{/* Add any upcoming events/streams/etc */} +The deeper change underneath that demo was relaxing a long-standing intercomponent-linking check. Previously the runtime rejected workloads where multiple sibling components exported the same interface (the messaging `handler` export, in this case) because there is no way to tell which instance to invoke — that is genuinely ambiguous if another component inside the workload is trying to **import** that export. But if no component imports it — the host is the one that decides which component instance to call, based on the subscription topic — the workloads are not ambiguous, just multiply-exported. The PR keeps the cycle check on imports and lifts it on duplicate exports when nothing in the workload pulls them. The result: a workload can host three components that all export `wasi:messaging/handler`, each bound to a different subject, and the host's routing layer picks the right one per message. The host-side **in-memory messaging plugin** was updated alongside this to do that subject routing locally. If a `WORKLOAD_NATS_URL` is set, the workload automatically loads the NATS plugin instead — but the in-memory backend stays the default so first-run demos do not need any external infrastructure. -- WASIP3 vote is tomorrow +For a developer who runs into the multiple-exports check elsewhere, the workarounds are still the same: compose the components together with [`wac`](/docs/wash/) so each external import is bound to a specific instance, or split the components into separate workload deployments. The change makes the in-workload, host-routed case work without forcing either. -### Catch up… +### wasmCloud 2.3.0 and Kubernetes-Native Ingress -{/* Add any blog posts/articles that the community might find interesting */} +Jeremy then handed Eric Gregory the documentation slot with two updates from the [**wasmCloud 2.3.0 release blog**](/blog/wasmcloud-2-3-0-release/) that shipped the week before. The release includes the workload **env config and secrets** surface in `wash` config YAML for `wash dev`, OpenTelemetry fixes, and a new example host (`loud`) that demonstrates how a workload component's egress can be observed and controlled — a small pattern useful for socket-isolation walkthroughs. -- +The bigger documentation update is the [**Kubernetes-native ingress architecture**](/docs/kubernetes-operator/operator-manual/overview/#architecture) page under the operator manual. The previous Wasm-on-K8s ingress path went through a wasmCloud-specific *runtime gateway*; that gateway is deprecated in favor of using **plain Kubernetes Services and Endpoint Slices**. The architecture page now walks the whole request shape: an Ingress front-ends a Service, kube-proxy resolves the Service to the Endpoint Slices that the runtime operator registered for the workload's host pods, and each host pod routes incoming requests to the right Wasm component based on header and path matching. This is the same plumbing every other Kubernetes workload uses and it composes cleanly with cluster-standard ingress controllers, cert-manager, etc. -## Recording +### WASI P3 Launch Vote -{/* Automated - No need to adjust this unless automation fails */} +The last and biggest item: the **WASI P3 launch vote** is scheduled for the day after the call. Bailey walked the state. Eric has a [`wasi.dev`](https://wasi.dev/) refresh PR in review that reorganises the Preview-3 messaging and calls out the [WASI test suite](https://github.com/WebAssembly/wasi-testsuite). Victor Adossi and Tomas Hribernik got [**JCO** test-suite compliance](https://github.com/bytecodealliance/jco) over the line, which makes JCO the **second reference implementation** alongside [Wasmtime](https://wasmtime.dev/). Anyone can pull `main` of the WASI test suite, run it against JCO, and see the pass. Two reference implementations is exactly what the subgroup needs for the vote, and if it passes WASI P3 launches. - +What that unlocks downstream: + +- **wasmCloud will enable WASI P3 by default**, shortly after the vote. +- **Alex Crichton's Wasmtime PR** to flip the **component-model async feature flags on by default** lands in **[Wasmtime 47](https://wasmtime.dev/)**. Wasmtime 46 already branched and is in continuous fuzzing, so 47 is the realistic landing window for async-by-default. +- Bailey will cut a wasmCloud release that **bundles WASI 0.3.0 WIT interfaces** into the published OCI artifacts so guests have one canonical place to pull the new world from. + +She also called out Aditya Salunkhe's PR on **sharing values inside the same component-model store** as a great piece of work, with a follow-up conversation about the multi-store design that will land on a future call. + +## WebAssembly News and Updates + +This call is a snapshot of the WebAssembly ecosystem putting the final pieces in place for the **WASI P3** launch. With JCO joining Wasmtime as the second reference implementation, the [Bytecode Alliance](https://bytecodealliance.org/) and the [WASI subgroup](https://github.com/WebAssembly/WASI) have a clear path to a passing launch vote. On the runtime side, the [`wasi.dev`](https://wasi.dev/) refresh, the imminent Wasmtime 47 async-by-default flip, and OCI artifacts pre-bundled with WASI 0.3.0 WIT interfaces all converge into a single moment when **component-model async**, [WASI P3](/blog/wasi-p3-on-wasmcloud/), and [native async I/O](https://tokio.rs/) land in production runtimes at the same time. On the platform side, **wasm runtime autoscaling on Kubernetes** now uses the standard HPA contract through KEDA, and the deprecated runtime gateway is replaced by plain Kubernetes Services and Endpoint Slices — making this the cleanest Wasm-on-Kubernetes story to date. For ongoing **webassembly news**, follow the [Bytecode Alliance](https://bytecodealliance.org/) and the [wasmCloud blog](/blog/). + +## What is wasmCloud? + +[wasmCloud](/) is a CNCF project for building applications out of [WebAssembly components](/docs/overview/workloads/components/) and deploying them across cloud, edge, and [Kubernetes](/docs/kubernetes-operator/) clusters. The [Wasm component model](/docs/overview/workloads/components/) lets you write business logic in Rust, Go, Python, TypeScript, C#, Java, and more — while the platform handles capabilities like HTTP, messaging, key-value storage, and observability through a pluggable [host plugin](/docs/overview/hosts/plugins/) architecture backed by [Wasmtime](https://wasmtime.dev/). [`wash`](/docs/wash/) is the developer shell — build, run, deploy, debug — and the [runtime operator](/docs/kubernetes-operator/) schedules Wasm workloads on Kubernetes the same way you schedule container workloads, with built-in [OpenTelemetry observability](/blog/otel-observable/), HPA-aligned autoscaling, and native [WASI P3](/blog/wasi-p3-on-wasmcloud/) support landing. The result is the production substrate for **WebAssembly on Kubernetes** and the edge. + +## Topic Deep Dive: Wasm Runtime Autoscaling on Kubernetes + +The headline change in this call is the alignment between **Wasm runtime autoscaling** and the Kubernetes [Horizontal Pod Autoscaler](https://kubernetes.io/docs/tasks/run-application/horizontal-pod-autoscale/). Container platforms scale by adding pods because each container is the unit Kubernetes schedules. wasmCloud workloads are different: a single host pod runs many Wasm component instances, and the platform earns its density by **not** spinning up a fresh pod per workload. So the autoscaling problem becomes: how do we adopt the standard HPA contract — which assumes "scale this resource to N replicas" — without losing that density story? + +The answer landing in this PR is that the [workload deployment CRD](/docs/kubernetes-operator/) now implements the `/scale` subresource directly. The HPA sees a standard resource with `spec.replicas` and a label selector and treats it like any other scalable thing. KEDA layers on top by reading any Prometheus metric — request volume, queue depth, ingress back-pressure — and feeding the HPA an external metric. What scales up and down is the **Wasm workload instance count inside the existing host pods**, which is exactly the right knob: the platform reuses host capacity, OTel-emitted metrics drive the controller, and the user gets the familiar HPA observability surface. Pair it with the [Kubernetes-native ingress story](/docs/kubernetes-operator/operator-manual/overview/) and the upcoming Helm-configurable [NATS](/docs/overview/transport/) and you have the first end-to-end Wasm autoscaling story that looks indistinguishable from container autoscaling to a platform engineer — which is, in turn, the foundation for [running mainstream services as components](/blog/how-to-run-webassembly-components-on-kubernetes-with-wasmcloud/) at production scale. + +## Who Should Watch This + +This call is especially valuable for **platform engineers** evaluating Wasm autoscaling on Kubernetes ([0:12](https://youtu.be/v0o4ptC_jqQ?t=12)) — the demo is a complete walkthrough of the HPA contract on a real Kind cluster — **SREs and infrastructure teams** running their own NATS clusters who want to plug Synadia or external NATS into the wasmCloud Helm chart ([11:36](https://youtu.be/v0o4ptC_jqQ?t=696)), and **component-model developers** building multi-handler workloads who want to see the single-`wash dev` multiple-subscription pattern in action ([13:14](https://youtu.be/v0o4ptC_jqQ?t=794)). Anyone tracking the [WASI P3](/blog/wasi-p3-on-wasmcloud/) launch should jump straight to Bailey's status update at [24:21](https://youtu.be/v0o4ptC_jqQ?t=1461) — the vote that follows it changes the WebAssembly roadmap for the rest of 2026. + +## Up Next + +The next community calls are framed by the **WASI P3 launch vote** the morning after this one. Watch for wasmCloud enabling WASI P3 by default, an OCI release with the WASI 0.3.0 WIT interfaces bundled in, the component-model async feature flags going on by default in [Wasmtime 47](https://wasmtime.dev/), and a deeper conversation with Aditya Salunkhe on multi-store value sharing inside the component model. The Helm-chart NATS overhaul and `wash dev`'s per-component config both ship in the next release, and Jeremy's autoscaling test harness should land in [Cosmonic Labs](https://github.com/cosmonic-labs) so anyone can replay the scale-to-38 demo on their own cluster. + +{/* TODO: Link to next meeting page once created */} + +## Get Involved + +wasmCloud is a CNCF project and contributions are welcome. Join the community: + +- [GitHub](https://github.com/wasmcloud/wasmcloud) — star the repo and check out open issues +- [Slack](https://slack.wasmcloud.com/) — join the conversation +- [Community Meetings](https://wasmcloud.com/community/) — every Wednesday at 1:00 PM ET +- [wasmCloud Blog](https://wasmcloud.com/blog/) — latest news and releases + +## Full Transcript + +Read the complete transcript with speaker labels and timestamps: + +**[Read the full transcript →](/community/2026-06-10-community-meeting-transcript/)** diff --git a/src/data/transcript-inheritance.json b/src/data/transcript-inheritance.json index 544cc5f2..e893476d 100644 --- a/src/data/transcript-inheritance.json +++ b/src/data/transcript-inheritance.json @@ -1,6 +1,6 @@ { "$comment": "Auto-generated by scripts/generate-transcript-inheritance.mjs (prebuild step). Edits will be overwritten. Maps transcript permalink → { about, mentions } from the parent landing page's frontmatter so video-seo.tsx can inherit entity refs.", - "generated_at": "2026-06-10T19:02:48.387Z", + "generated_at": "2026-06-11T08:48:12.549Z", "entries": { "/community/2022-11-02-community-meeting-transcript/": { "about": "wasmCloud", @@ -2082,6 +2082,19 @@ "ComponentModel", "xtask" ] + }, + "/community/2026-06-10-community-meeting-transcript/": { + "about": "wasmCloud", + "mentions": [ + "Kubernetes", + "WASIPreview3", + "Wasmtime", + "NATS", + "JCO", + "ComponentModel", + "wash", + "runtimeOperator" + ] } } }