Transcript: WebAssembly News: NATS Stays in the CNCF & the wasmCloud Q2 Roadmap
wasmCloud Weekly Community Call — Wed, May 7, 2025 · 27 minutes
Speakers: Brooks Townsend, Lachlan Heywood, ossfellow
Transcript
Brooks Townsend 01:44
Hello everybody. Welcome to wasmCloud Wednesday for Wednesday, May the seventh. We have got a pretty quick agenda for today — so quick we didn't even put it up on the website, which is awesome. So just a couple quick discussion items and things to call out. I think it would be good to just go over the roadmap, since we're into May now, so it'd be good to touch base on it. But first I have a bit of an update.
So on the CNCF blog earlier — well, it was actually last week, but after the community call — we had a discussion around the NATS project and where wasmCloud stands. Of course, to reiterate: we stand with the CNCF, with open source software. wasmCloud will always be Apache 2, and it looks like for the future of the NATS project, it will also be Apache 2, and the trademark will be under the CNCF. I don't think there are really any plans to change much; this is basically what it was before. I know there was a lot of concern around the future of NATS.
So there are definitely places in wasmCloud where we are, I would say, accelerating — where we're pushing transport-agnostic stuff, like on wRPC to be able to use QUIC and TCP and Unix domain sockets, and then on the control interface, for example, to have some different options, especially in places where NATS doesn't always play really well. So, for example, if you're running in Kubernetes, it might be really nice to have the state store be etcd and do the control interface over HTTP. I'm just mentioning random things when I say that we are pushing on that, but really it is interesting to be able to explore the best transport for the scenario that wasmCloud needs at that time. So plenty more to talk about there.
I think Masood's comment is a pretty valid one. We have a really good relationship with Synadia — I mean, we've been power users of NATS for so long. I wish that we kind of didn't go through this back-and-forth just to get to NATS staying in the CNCF. I can understand some of the frustrations on the Synadia side, but really, to sum it up, I'm just happy that we don't have to be concerned about NATS exiting the CNCF, and we can move forward doing the things we've been doing, and just continue trying to be the best WebAssembly project that we can be.
Do folks have any other comments? I've linked this blog post in the Zoom, but if you Google "CNCF, Synadia, and NATS," it's one of the first things that comes up. Do folks have any questions or comments here? I kind of just want to mention this one, and then hopefully we don't even have to worry about it again. Alrighty — just wanted to bring that to the attention of anybody who's paying attention to the calls who maybe missed some of the NATS side of things.
Brooks Townsend 05:42
Other than that, I think it'd be great to just take a look at the roadmap so far. We brainstormed and got quite a couple of issues put into this roadmap. A lot of them were already filed as issues on the open source board, or on the wasmCloud issue board — it wasn't a lot that actually came in net new. So, taking a look at some of the status of these: regarding wRPC error handling and custom interfaces, I know Eric, I think you actually have a PR up for this and you're just waiting on a review or a check mark. Is that right? Yep, that's right. As usual, can't trust any task taken by Eric to not get done immediately — this is great. We should be able to push this forward to be one of the first completed tickets from this roadmap.
As far as the things that are in "ready for work," there's quite a few in the good first issue category. Rabel — I'm sorry if I'm mispronouncing it — actually has a pull request up for this, which is great. Let me go ahead and move this into "in progress." This community member and awesome wasmCloud contributor came in and left a proposal for how they would want to fix it. We assigned the issue to them, which is exactly what I want to be happening with this good first issue column. So we've got quite a few in there which are ready at any time for folks to take as new or returning contributors.
As far as the development side, it looks like we have a couple in here that are ready for work as well, for anybody who is a little bit more familiar with the wasmCloud ecosystem — being able to do some diagnostics around the NATS provider, the get-inventory state, using environment variables for Blobstore S3, and then a somewhat larger feature: dropping the use of the wash directory by using the XDG Base Directory specification. This one's still a feature request, but open for comments as well.
As for the things that are not in "ready for work," let's see if we can move any of those over. The RFC to plug in wash — I don't know if Taylor is actually here, but we've been sitting on that RFC for a little bit. I think this one is probably not ready to take on the maintainer side; there are still some things to discuss and a POC to do on that story, so we'll leave that on here for now.
Workload identity and wasmCloud — I know we put this in triage because we wanted to determine the future of this feature. There's that open pull request on the SPIFFE/SPIRE repository that might change the way we do workload identity. So, TBD. Workload identity, especially for NATS connections or connections to the lattice, very much depends on the auth callout feature of NATS. So it'd be very nice to have a little bit more alignment that we can just move forward with something like that.
And then the deep design exploration of HTTP came from our road-mapping session — Lucas, I think we brainstormed this one together. This is around deeply exploring the HTTP use case end to end: component HTTP, built-in providers, external providers, and just really making sure that it's solid and we can catch errors and surface them in a way that's easy to understand. I suppose this is ready for the taking; I'll go ahead and mark this one as ready for work. It would be best taken by a maintainer or someone who's been working with wasmCloud for a little while, to help understand where the different failure points are, how we can best use tracing to diagnose issues, things like that.
"CI doesn't run when it should" — this one I think is actually an open question. Lachlan, you're here. I was looking at this. This happened right around the time that we ordered some of our CI to only run when specific things change. So, you know, we only run the wash CI if you change Cargo.toml or something in the wash directory. I haven't specifically called out something around the secrets-nats-kv implementation that's not triggering properly. Is this still an issue?
Lachlan Heywood 11:51
It has not been fixed. It has not been looked at or anything, so I'm assuming so. If you scroll up a little bit — yeah, that comment there. Basically it's just not running. The secrets-nats-kv is not a provider, so it doesn't actually get run in this piece, specifically when the Nix flake changed. So, basically we need to put it back in there, or make this secrets-nats-kv workflow more like the provider-based workflow, or included in that. I'm not sure which is better, but it basically is just not running when the flake changes.
Brooks Townsend 12:48
Okay, all right. Then this is probably a really quick one. I would say that we should put this one into "ready for work" and "good first issue."
Lachlan Heywood 13:01
It's great, yeah.
Brooks Townsend 13:01
Okay, great. I originally put it under development because I thought that we might have a broader CI thing to resolve.
Lachlan Heywood 13:11
Yeah. I think the quick fix is to just add the flake.nix and flake.lock files to that changed-files piece, and then it should cover everything. But the longer-term thing is, we do probably want to look at how we can make — I think the larger one is, how do we make it so that this doesn't happen again for anything new that gets added? And I'm not sure what the answer is on that. So if anyone has proposals or ideas on managing the pipelines, managing how things get triggered, and all that sort of stuff, happy to have an RFC discussion. However we want to organize that, that's open for suggestions there for sure.
Brooks Townsend 14:13
Yeah, awesome. And then the last one is the host configuration file. I really don't think that this one will be too hard to implement. The reason why it's in triage is just deciding on the design of the host configuration file — that, I think, is something best taken by a maintainer. We have a lot of different options for this. I'm not tied to any particular format — YAML, TOML, JSON, whatever. I think being able to set all of the existing flags and environment variables that we have just inside the config file would be the first step. But there are also other configuration pieces that we should be able to give to the host as well. We should probably decide on a scope for this one.
I'm thinking, for example, you can configure a host to always start with a specific configuration — maybe you give it a WADM file, or we even make it simpler and it's just a list of providers to start when the host starts. Things like that are all kind of in scope for what a host configuration file could be. The goal: we run wasmCloud hosts in a lot of different environments — sometimes just bare metal, sometimes a little edge device, sometimes Kubernetes. It'd be really nice to just have a single config file so that you can execute the binary or the container, pass it the file, and call it done. That would be really nice for a reproducible environment too.
I will touch base with Joonas, who I think wanted to take the lead on the initial proposal here, and just see where we're at with this one. I don't think it's really urgent — it's kind of a nice to have — but we'll just get the status on that.
So, yeah, on the wasmCloud roadmap for Q2, I think that we have a couple of outstanding things from Q1 that we probably need to either close out or move over. So I'll take a look at what needs to transition. Masood, I see in the chat you mentioned outgoing HTTP client tracing, which I believe was an issue from the Q1 roadmap. Is there anything that we needed to talk about here?
ossfellow 17:28
No, I'm just saying that because when I was doing it, I could not understand all the dependencies. As you know, HTTP in particular is a rabbit hole when it comes to how many hoops it jumps through, and that's why I started from the runtime, tracing all the way to the actual client. So if you turn on debugging — both for internal and external — then you should see, as it passes through different function calls and modules, exactly what's happening. Because of what you were talking about, I thought that this would be related. That's where I added that comment.
Brooks Townsend 18:31
Absolutely, yeah, thank you for the context. I think it's very related. Just like you said, being able to do it even just with Rust tracing and the logs is nice, but having this also exported to OpenTelemetry and everything would be really nice. The issue that we have right now is with a specific configuration: you send an outgoing HTTP request to some site and it hangs. It would be really, really useful to know — did this hang at the runtime layer? Did this hang when it hit the provider? Did it hang because we actually just got a 404, or the website never responded? I think this is super, super nice.
ossfellow 19:23
I think OpenTelemetry is included in all the functions, so that from a tracing perspective it's observable, and from a Rust tracing perspective it can be logged all in the wasmCloud log, and you can see exactly how things pass through.
Brooks Townsend 19:48
Yeah, exactly. It's really great. I think the only other thing — the PR I saw — you've done a little bit of refactors for reusability, which is really great. I'm really glad that you've been taking a look at this and trying to get it so that we can have just one piece of code for the HTTP client, whether it's built in or external. Really nice.
ossfellow 20:29
Okay. There is duplication, but that part is only where those things differ.
Brooks Townsend 20:37
Yeah, that makes sense. That's really all that we had today. We've got some free time — do folks have anything that they wanted to discuss from the wasmCloud ecosystem, or just generally?
ossfellow 21:08
I do have a question about one of the issues. I haven't raised my hand —
Brooks Townsend 21:13
Now you can go ahead, virtual hand raise.
ossfellow 21:18
I saw you opened the feature for turning the events to email. I wanted to find out — are you working on that?
Brooks Townsend 21:30
Yeah, so, no —
ossfellow 21:33
The reason is that I wanted to see if I could pick it up. But it wasn't really clear if you're actively working on it or you're just proposing it.
Brooks Townsend 21:45
Yeah, thank you. No, I'm not actively working on it, just proposing it. What I saw after creating this PR, where we have the event publisher — just a simple abstraction for publishing events — is that it's basically not assuming that we're publishing to a NATS topic, but letting you use any implementation. GitHub is going to have a hard time here, because it's a big PR, and it's of limited usability the way that we currently have this implemented. So the event publisher is just an event, ready to serialize to JSON.
When we generate something like a component-scaled event, our constructor is "hey, give me the claims, annotations, host ID — all the information that we need for the events" — and then we create that JSON structure. But what would be really nice, instead of having the concrete event… a component-scaled event includes all of these different fields that would make it a whole lot easier for this trait to match on the event and do something with it — the name, if we can turn the enum into a string. Masood, I think this one is welcome for anyone to take. I haven't started on it. I should probably get this PR merged in to aid in the development of that. Do you have questions on it, or have you seen the way that wadm implements this with a trait for getting the event name, and how wadm does that investigation?
ossfellow 24:40
I saw it, and I thought that it makes sense. The only question that came to my mind was: do we know what those events are? Do we have a list, or do I need to kind of fish it out of the host?
Brooks Townsend 25:01
Yep, great question. We do have a list. The list is moderately documented on the website.
ossfellow 25:14
I have seen that. Just kind of wondering whether that's up to date, or whether I need to make sure that there are no deltas.
Brooks Townsend 25:25
No, great question. There might be some delta — there shouldn't be much, but it's possible. The entire list of events is in this events.rs file, corresponding to all of the different public methods that we have here. I believe that this is all that we have. It'll be easy to search all the different places where we call publish-event to find it. That's a good clue.
ossfellow 26:00
That's a good clue. Thank you.
Brooks Townsend 26:03
Yeah, of course. And if there's any delta between this and the documentation, please let us know — always welcome to open up a PR to the doc site and everything, just to make sure we're totally up to date.
Well, alrighty, I think that might be all for today's wasmCloud Wednesday. Thanks everybody for coming, hanging out, talking wasmCloud — glad to just keep pushing forward all the stuff that we have on the roadmap. As always, if you have any questions about an open issue that you're interested in taking, feel free to reach out to any of the maintainers, myself included, for some initial pointers or guidance. Have a great week everybody. Have a wasmCloud day, and see you next time.