title | authors | tags | description | |||
---|---|---|---|---|---|---|
2023-10-18 Community Meeting |
|
|
Agenda, notes, and recording for the 2023-10-18 community meeting |
import ReactPlayer from 'react-player/youtube';
- 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
{/* truncate */}
- 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 WebAssemblywash build
enables building and signing actors for running in wasmCloud- You could build the Wasm module manually (ex. in Rust, using
cargo
) and use thewash claims sign
CLI to manage the claims on the module.
- You could build the Wasm module manually (ex. in Rust, using
wash build
makes it possible to put that config inwasmcloud.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.
- Taylor jumped in
wasmcloud.toml
contains configuration (e.x. metadata and build options) that controls howwash
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 targetwasm32-wasi
(AKAwasm_target = wasm32-wasi-preview1
)a
- Originally what we did was compile code to
- 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
- compiling the code to
- ⚠ 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
- Command:
- 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 underwasmCloud
- 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 withwash 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 (usejust
to see a list of available commands)
Brooks showed the code, and walked through lib.rs
and the WIT
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.
- 📖 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.
- 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
andwascap
, 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
- He'd like
- 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.
- 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.
- Bailey chimed in
- 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.
Talk: Orchestrating Wasm: Reconciliation loops aren't owned by Kubernetes
Talk: Bringing Cloud Native Wasm to the mainstream