Skip to main content

2024-02-27 Community Meeting

Brooks Townsend

Agenda​

  • DEMO: Components communicating with wRPC
  • DISCUSSION: wRPC: check-in on progress
  • DISCUSSION: Quick check-in on the 1.0 roadmap

Meeting Notes​

DEMO: Components communicating with wRPC

  • In wasmCloud, runtime linking between WebAssembly components and capability providers is accomplished through a new and dedicated protocol—wRPC. We discussed this a little last week. This replaces the earlier wasmbus protocol.
  • Take a look at the open RFCs for more details.
  • Much like gRPC but is specifically designed for the unique needs of WebAssembly Interface Types (WIT). It utilizes NATS queue groups to create a unidirectional linkage that facilitates communication and collaboration between components and providers.
  • This week we’re showing how components communicate with wRPC. As always, there’s only so much we can cover in notes—take a look at the recording for the demo.
  • We show that it’s no longer necessary to compose and link components at compile time, we can now compose components at runtime and connect them over the lattice using wRPC.
  • Tl;dr, this is how components will talk to each other in the future. This is a terrific demo, check out the recording below and join the discussion at slack.wasmcloud.com

Q&A:

  • Colin: If actors are on same host is everything sent over NATS or is there a short circuit?

    • Yes, over NATS. Because the functions are so strongly typed it’s easier now to find the target of the invocation and call the functionality. Networking is a potential bottleneck and so we can see a time when we will add local invocation capabilities.

  • Is there something like that planned for the next version of Wasmtime?

    • For P3 the Bytedode Alliance has talked about ‘post components’ which is a similar implementation to the way we do capability providers. Running code that is not a component but being able to extend the security model to it. It’s early days here but the goal is to support what happens in the community.

  • Jordis: What are the implications for the current capability provider model—what will change?

    • We have a few questions in the wasmCloud Slack channel over the last few weeks around building custom capability providers and whether they should be in smithy or WIT, and what the new provider SDK is. We appreciate everyone’s patience—we do have a sweet new provider SDK (as yet undocumented) and a new bindgen macro so, when it comes to capability providers, there will be far less change than you think. Right now, NATS uses WIT to generate structure and types and so some degree functions.

  • Not sure if this is true but seems the WIT file will take on the role to marshall a specific message payload.

    • The WIT file will be used to describe all your types structures, functions, what you’re planning to invoke. But it is agnostic to the protocol or the marshalling and transition format. That is still handled opaquely to the developer.
    • We can see a world where we may need to bring some customization here.

  • Jochen: Provider vs component - this is a little confusing.

    • The way we think of provider is a privileged actor - one is stateless (components) and one is stateful (providers). Stateful - connection pools, machine learning models. Long-lived elements.

  • Privileged actor— we are looking into how we store creds or secret info in the link - clear text is a little tricky.

    • Yes! We have some updates there. Now, when you put a linkdef you’re not posting the full config map as part of the linkdef - you’re linking a source to a target and providing a list of names for config that the source or target may beed. We so this by pulling he config from an external location.
    • Designed to be more flexible and reusable. We may not always want to store this type of into in jetstream - we may want to pull config from K8s to satisfy a component link, or a secret store and
    • Tooling will look similar - we will have an easy way of assoc and designing config. More to come here soon.

DISCUSSION: wRPC: check-in on progress

  • Now you’ve seen wRPC in action, let’s look deeper at progress on the MVP. You can see our open issues here.
  • MVP integration issue - we are tracking a couple of open PRs. Check out high level update in the readme.

DISCUSSION: Quick check-in on the 1.0 roadmap

  • You can see the detail in Github here
  • We have completed a ton of work over the last few weeks. The major focus is getting wRPC in place and operational.
  • Next and ready for work comes with removing some of the claims signing. All discernable with WIT and linked together at runtime.
  • We are well on the road to the release of 1.0!

Where we’ll be…

March 14 - 15 We’ll be at WASM I/O in Barcelona which really is becoming a highlight event. Be sure to say “hi” if you’re there and get your tickets early.

March 19 - 22 We’ll also be in Paris for KubeCon + CloudNativeCon EU 2024 and Cloud Native Wasm Day plus a host of other co-located events. The schedules are live!

April 16 - 18 Taylor will present at Open Source Summit NA. Check out his talk: Mind the Gap Between the Future and the Present taking place 16th April, 12:15pm - 12:55pm PT.

Listen in…

  • Check out the Arm Developer Podcast where Bailey and Liam discussed the intersection of Wasm and GPU technologies.
  • Cosmonic CTO Bailey Hayes met Chris Matteson (Fermyon) and Oscar Spencer (F5 NGINX) on the panel at the latest Kubernetes meetup in New York. They explored the Wasm what’s, why’s, standards and considerations when adoption. The recording is live!
  • Listen in to the last WasmEdge community meeting where Bailey Hayes talks all things WASI 0.2 and we hear from the students of the University of Tokyo on some cool new projects.
  • Bailey was a guest on a recent Rancher Live podcast with Divya Mohan. Tune in for a deep dive into WASI 0.2!

Recording​