2023-10-18 Community Meeting

Agenda

• DEMO: wash build and progress to working with wasi-preview-2 components
• DISCUSSION: wasmCloud security audit
• DISCUSSION: wasmcloud/wasmcloud monorepo
• DISCUSSION: Accepting ADRs
• DISCUSSION: Give an update about the community's growth and WASI-virt

Meeting Notes

DEMO: wash build & progress to WASI Preview 2

• Brooks demo'd VSCode (in dark mode) with
• If you've built Webassembly while working with wasmCloud before, you've been using wash build
• wash build started as a light wrapper around toolchains to compile to WebAssembly
• wash build enables building and signing actors for running in wasmCloud
  • You could build the Wasm module manually (ex. in Rust, using cargo) and use the wash claims sign CLI to manage the claims on the module.
• wash build makes it possible to put that config in wasmcloud.toml, and get consistent tooling across languages.
  • Taylor jumped in
    • The Webassembly community is working on it, but once they get to that place, then we're going to have one of the easier ways to build a component.
• wasmcloud.toml contains configuration (e.x. metadata and build options) that controls how wash will configure itself.
• You can find out more by heading to the docs site and searching for wash build.
• We've had support for actor.wasm_target for a while now
  • Originally what we did was compile code to wasm32-unknown-unknown (with older tooling we didn't use WASI for communicating across component boundaries)
  • What actor.wasm_target lets you do is target wasm32-wasi (AKA wasm_target = wasm32-wasi-preview1)a
• We've also added wasm_target = wasm32-wasi-preview2, which does the hard parts of the toolchain for you (no language toolchain supports this right now).
• Compiling to wasm-wasi32-preview2 means:
  • compiling the code to wasm32-wasi (i.e. WASI preview1 WebAssembly module)
  • adapts the preview1 component to preview2 using a component adapter
• ⚠ There are unfortunately lots of ways to stub your toes currently on the WebAssembly toolchain while trying to build Preview2 components, so there maybe be errors!
• Once your module is built, we can use wasm-tools to see the component model imports and exports.
  • Command: wasm-tools component wit path/to/file.wasm
• A great example to follow is kvcounter-wasmcon2023 in wasmCloud/examples
  • Use the just commands in there to run commands (run just to get a list of available commands)
• For stuff like Preview2 to work, multiple things have to match up:
  • WASI spec & WIT definitions in the adapter
  • WASI spec & WIT definitions in the component itself
  • Underlying engine that's going to run the module (wasmtime version under wasmCloud
• The rapid upstream changes makes it hard to make the flow simpler/less error-prone for now, the standards are making great improvements quickly.
• Any time you have a preview1 component, you can adapt it to a Wasm preview2 component -- this workflow is required no matter what language you're using -- Rust, TinyGo, ETC
• We went over the kvcounter demo Rust code
• After building actors with wash build, we can inspect the resulting Wasm module with wash inspect
• If we use wasm-tools component wit on the web assembly component that is built to see the imports and exports that are expected.
• The host expects the interface that WASI provides here, so components that run on it must provie those.
• You can use the just run-actor in the repo to do some of the local things that are possible there (use just to see a list of available commands)

Question: how does the code look like? (Kevin)

Brooks showed the code, and walked through lib.rs and the WIT

Question: is write_http_response generated by wit_bindgen or is that from somewhere else (Kevin)?

It's a custom function that's written but it's necessary to write the HTTP responses using the WIT machinery, according to the WIT contracts.

ANNOUNCEMENT: wasmCloud Security Audit

• 📖 Trail of Bits security assessment
• WasmCloud received a security audit from the folks at Trail of Bits.
• TL;DR is that "WasmCloud is a well reviewed project, with lots of diligence in it's security posture. THis has paid off, as evidenced by this audit, which had no severe or high issues to resolve.
• Kudos to Kevin the founder of wasmCloud who made decisions that paid off with respect to security, making sure to secure access with keys.
• Feel free to peruse the low criticality vulns that were found, and note that they have all been resolved and released as patch versions at this point.
• Thanks to CNCF for sponsoring the security audit w/ Trail of Bits.
• This is a great step forward for moving the wasmCloud project along within the CNCF.

DISCUSSION: Managing the wasmCloud GitHub organization repos

• We've talked a lot about reorganizing the orgs in the past, and we still have a lot of repos in our org.
• We've noticed some friction working across many repositories in the past.
  • For example, Brooks was working on a change to the control interface client crate. Updates had to be made to capability providers, wasmcloud, and other crates to properly propagate the changes.
• With all the code in a single repo, we would be able to test all of it and push all the changes at the same time.
• There are various pros/cons to monorepos, and we don't want to start a holy war here
• The basic approach is to push crates that have wasmCloud as a primary consumer into the wasmCloud repository.
• Connor & Roman just put up PRs that merge in wash and wascap, for example.
• It should be possible to head into wasmCloud/wasmCloud and contribute changes across multiple repos
• Not everything will go into wasmcloud/wasmcloud -- wadm is unlikely to go in, for example, because it is not necessarily released on a cadence with wasmCloud.
• Connor chimed in
  • He'd like wasmcloud-otp moved into the repo
• This is a heads up to the community that we've started the work to move everything into the monorepo, with the goal to make it easy to contribute to individual components in there.

DISCUSSION: RFCs

• Another thing we've talked about in the past -- RFCs.
• Normally we move RFCs through discussion in the past
• The Host Metrics RFC is a great example, thanks to Patrick for putting it up
  • The last time we commented on this was
• While we have a process around RFCS to propose, accept & close -- we don't have an official process for moving something from proposed to accepted.
• It would be a good idea for maintainers in the relevant project to vote on accepted RFCs to move them from proposed to acepted.
  • Once it's been accepted, we could push the RFC through to the roadmap.
• What we're going to ask Patrick to do (like other RFC proposers) is to put a comment tagging relevant maintainers to ask for approval after a couple of rounds for discussion.
  • To somewhat formalize it we can specify something like "2 maintainers have to approve".
• We want to be clear about how we deal with the RFCs, and their status but don't want to add too much formality.
• Any thoughts on things that work really well/don't?
  • Bailey chimed in
    • Great idea brooks!
    • Something that worked well here was Kubernetes's KEPs
    • We do something similar in the ByteCode Alliance (BCA)
    • They also took into account contributors from different companies
    • There are different levels of where you need to drive consensus.
  • Taylor chimed in
    • Don't want to overdue anything, but I do think we have a gap between RFCs and ADRs.
    • One thing I worry about closing an RFC is keeping it open and visible.
    • Closing an RFC stops them from being open & visible.
    • Having a place that it turns into the README document is important.
    • We could soften what we call an ADR to allow for in-discussion statuses
  • Victor chimed in
    • What about putting it in the repo?
    • Brooks: This works but it needs to be really accessible
    • Bailey: Do RFCs always turn into ADRs?
    • Bailey: We want to leave space for people to YOLO and get thoughts
    • Brooks: Jordan brought up GitHub discussions which could work great.
• Not every RFC is an architectural decision
• Let's try a bunch of things, without going too crazy
• Once an RFC is done, we file the ADR and close the original issue.
• We have a status field for a reason, it's a good idea to accept an RFC and turn it into a README.

Don't forget: 🗓 WasmDay 2023 on November 6th

The event is on November 6th!

Talk: Orchestrating Wasm: Reconciliation loops aren't owned by Kubernetes

Don't forget: Cosmonic @ Kubecon NA 2023

Talk: Bringing Cloud Native Wasm to the mainstream

Talk: Serving backends like frontends

Talk: Serving backends like frontends

Recording