Proposing a SIG As explained in the Bytecode Alliance Technical Steering Committee charter, any member of the Bytecode Alliance can propose the creation of an Interest Group. [ ] Write a proposal to create the SIG, clearly identifing its scope and goals, and list the member(s) supporting its creation. It is helpful to also have the proposal suggest willing Chairpersons for the SIG. [ ] Submit the proposal as a pull request to the SIGs directory of the governance repository of the Bytecode Allicance GitHub organization with a request for members to comment to be added as a supporting member to the proposal. TSC has the approval authority for the SIG. For an example, see the SIG-docs pull request. [ ] The TSC will consider the proposal and make a decision in a reasonable timeframe. It may adopt the proposal as made, but it can also modify the proposal if it believes it necessary. If approved the TSC will formally appoint one or more Chairs, who should follow the steps below to establish the SIG. Establishing a SIG Bytecode Alliance SIGs operate transparently and in full public view, open to participation by all. Approved SIGs therefore require a variety of resources to support their operation. For help with any of these contact David Bryant, Bytecode Alliance Executive Director, at david@bytecodealliance.org

This is a draft, please add comment, add yourself to the list of supporting members, and take initiative on fixing syntactical nits. SIG registries proposal for reference This document is a proposal to create SIG-Documentation as a formal Special Interest Group (SIG) under the auspices of the TSC of the Bytecode Alliance, as specified in the TSC's charter. SIG-Documentation's goal is to create, maintain, and promote documentation of the Bytecode Alliance ecosystem. The scope of the SIG focuses on ecosystem-wide documentation, such as documentation of the component model; rather than on tailoring documentation of specific Bytecode Alliance projects. However, the SIG may give recommendations to projects on how to best structure their documentation for consistency within the Bytecode Alliance. The group may also create open source tooling to help generate documentation, such as reference documentation of WIT interfaces (wit-docs-gen).

What to name the package? The spin software validation tool has claimed the spin package name in many OS package managers (brew , apt , chocolatey at minimum). Some alternative naming options: fermyon-spin spin-up Which installers Package Manager

interface "wasi:kv/data/readwrite" { use { Error, payload, key } from "wasi:kv/types" // Get retrieves the value associated with the given key. It returns an Error if the key does not exist. get: func(key: key) -> result<payload, Error> // set creates a new key-value pair or updates an existing key-value pair. set: func(key: key, value: stream<u8>) -> result<_, Error> // delete a key-value pair. If the key does not exist, it returns an Ok() result.

Krustlet is a open source project that enables WebAssembly workloads to run natively on Kubernetes. It does this by implementing the kubelet API, scheduling WASM modules instead of Pods upon requests from the Kubernetes scheduler. Kubernetes' Device Plugin framework enables Kubernetes workloads to request extended resources, such as hardware, advertised by Device Plugins. While krustlet currently supports CSI plugins, it does not support Device Plugins. This documentation goes through the work needed to be done to enable device plugin support. Investigation Upon startup, the Kubernetes kubelet registers two Plugin Handlers, one for CSI plugins and the other for for device plugins. Krustlet has currently implemented the equivalent of the CSI Plugin Handler as a PluginRegistry in its plugin_watcher module. The PluginRegistry implements both the plugin registration API -- which despite its agnostic name, is not for Device Plugins -- and PluginHandler interface. Kubernetes' kubelet has one pluginManager to which the CSI and DP PluginHandlers register. The pluginManager.reconciler makes sure that all plugins are in the correct (registered or deregistered) state. For example, it checks to see if a socket no longer exists for a plugin that is in the registered plugin list of thepluginManager.reconciler.actualStateOfWorld. If so, it will unregister the plugin by calling the associated PluginHandler's deregisterPlugin function. Therefore, plugin management in Kubernetes consists of the following: