Skip to main content
← Back

May 29, 2024

Agenda​

  • DEMO: Postgres Provider (PR)
  • DISCUSSION: CNCF incubation: process changes incoming from the CNCF Technical Oversight Committee
  • DISCUSSION: Secrets in wasmCloud: RFC
  • Featured docs: Using the wadm API
  • Postgres Provider (PR)

Community​

Meeting Notes​

DEMO: Postgres Provider (PR)​

  • An exciting new development on the provider front. Postgres provider and interface, developed and explained by Victor.
  • We had 2 SQL interface providers in the Smithy days - 1 for Postgres and one for DynamoDB. These were never perfect and are now defunct, but they contained a few useful components.
  • 1.0 allows us to go back and port some of the useful the old code but newly imagine the interface. This allows us to create a decent database for accessing providers. Anything useful should have a stateful component.
  • WASI Interface Types (WIT) interface is the most notable element. This is, essentially, a WIT interface for what Postgres should look like with the benefits of a Postgres-specific interface.
  • Resource: everything you need to know about WIT.
  • Using WIT means that multiple components can link to the provider, and each component can have multiple connections. WIT also has support for opaque types - the ability to return a placeholder that only the part of the program that performed the action needs to know about.
  • We can only say so much in notes. Check out the recording below for Victor's excellent demo.

Q: Robin aren't some of these implemented by postgres extensions? Is there a distinction being made between "core types" (or whatever they're called) and extension types and a way being provided to extend these?

  • Only core types: Regular Rust Types, WIT (type system for the component model), Postgres types. Most additional types align to Postgres types. Postgres well-known for a wide range of extensions; fertile ground for exploration.
  • There were a host of other comments and questions and so check out the recording.

DISCUSSION: Secrets in wasmCloud: RFC​

  • In the plan for a while and wanted Secrets to be accessible from components and providers on wasmCloud. The idea is Secrets will be a first-class construct in wasmCloud.
  • The idea is the host mediates connections between a provider or a component that is requesting app Secrets from a back end.
  • Similarly to config and policy services we can point it at a well-known program that it can make requests to; listening on NATS to it can satisfy the request.
  • Dispense Secrets, defined in Wasm. Pass grid references for Secrets that can be shared securely.
  • Many diff Secrets systems common in most organizations. For instance, we may have several diff Vault clusters - all accessible from the same wasmCloud host. The proposal talks about how we make sure this is all represented.
  • Essentially, it's the same underlying core, listening on different subjects. It's also cecure - NATS x-keys are used for dynamic encryption of all requests.
  • Wadm: specify Secrets. Secret has a name and a source in the Wadm manifest.
  • WIT definition is particularly cool as it inherently builds in the notion of a reference. You can be strict about how we access Secrets in scope of a component or provider. Audit and code every place a Secret is used to ensure they are not compromised.

Q: Colin Murphy Consideration; what happens when don't want every execution of a Wasm to connect to a Vault.

  • The host needs to cache - sits between component and Secrets back end. When it instantiates a component, the host resolves Secrets then and there.
  • When the component starts and is provided the handle. If you want to change your Secret you roll versions via Wadm.

DISCUSSION: CNCF incubation process changes incoming from the CNCF Technical Oversight Committee​

  • Taylor has written a blog about this so take a look for the full download.
  • CNCF TOC has created a much more streamlined process which should be great for the entire community.
  • We may be reaching out to some of you in the community to assist
  • Wadm 0.12 is here. Check out the docs (linked above) to see the changes included in this update.
  • We also released Crates! See the recording for more detail.

Community Updates​

Tune in…​

  • Cloud Native Live this week focused on all things Wasm and Kubernetes. Dan Norris and Taylor Thomas's stream: "Advanced Kubernetes Integrations with wasmCloud" looked at some advanced extension points work, using the wasmCloud operator as the backdrop. Watch to find out how we integrated Wasm into Kubernetes using Rust and extension points like Endpoint Slices, API aggregation and more!
  • On Cloud Native Live, Taylor joined Synadia's Jeremy Saenz to discuss the benefits of building a distributed Wasm-native reconciliation loop with NATS JetStream. Watch to learn about key-value buckets, streams and work queues, how they work and why they matter. 12 midday ET.
  • Bailey recently joined Dan Lorenc at Chainguard to discuss all things Wasm, Kubernetes, distroless compute models and more. Tune in for this step-by-step exploration of Wasm.
  • The CNCF and Bytecode Alliance came together on CNCF Cloud Native Live for an interesting discussion on WASI 0.2 the Component Model..and the role of the BA in driving forward Wasm standards and tooling.
  • Cloud Native Wasm Day recordings are available! Particular highlights are presentations from our community users MachineMetrics and Orange.
  • Check out the Arm Developer Podcast where Bailey and Liam discussed the intersection of Wasm and GPU technologies.
  • 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​