Skip to main content
← Back

April 3, 2024

Agenda​

  • DEMO: The 1.0 Wadm manifest
  • DISCUSSION: Capability providers in GHCR
  • DISCUSSION: 1.0 Roadmap Check-in

Meeting Notes​

Updates to wadm​

Brooks discussed changes to wadm for wasmCloud 1.0. With capability providers now communicating over WIT interfaces, wadm manifests now define links differently. Brooks compared the old version of a wadm manifest to the forthcoming version:

Old version:

yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: rust-http-hello-world
  annotations:
    version: v0.0.1
    description: 'HTTP hello world demo in Rust, using the WebAssembly Component Model and WebAssembly Interfaces Types (WIT)'
    experimental: 'true'
spec:
  components:
    - name: http-hello-world
      type: actor
      properties:
        image: file://./build/http_hello_world_s.wasm
      traits:
        # Govern the spread/scheduling of the actor
        - type: spreadscaler
          properties:
            replicas: 1
        # Link the HTTP server, and inform it to listen on port 8080
        # on the local machine
        - type: linkdef
          properties:
            target: httpserver
            values:
              ADDRESS: 127.0.0.1:8080

    # Add a capability provider that mediates HTTP access
    - name: httpserver
      type: capability
      properties:
        image: wasmcloud.azurecr.io/httpserver:0.19.1
        contract: wasmcloud:httpserver

New version:

yaml
apiVersion: core.oam.dev/v1beta1
kind: Application
metadata:
  name: kvcounter-rust
  annotations:
    version: v0.0.1
    description: 'Kvcounter demo in Rust, using the WebAssembly Component Model and WebAssembly Interfaces Types (WIT)'
spec:
  components:
    - name: kvcounter
      type: actor
      properties:
        image: file:///Users/brooks/github.com/wasmcloud/wasmcloud/examples/rust/actors/http-hello-world/build/http_hello_world_s.wasm
      traits:
        # Govern the spread/scheduling of the actor
        - type: spreadscaler
          properties:
            replicas: 1
        # Compose with KVRedis for wasi:keyvalue calls
        - type: link
          properties:
            target: kvredis
            namespace: wasi
            package: keyvalue
            interfaces:
              - atomic
              - eventual
            target_config:
              - name: redis-connect-local
                properties:
                  URL: redis://127.0.0.1:6379

    # Add a capability provider that mediates HTTP access
    - name: httpserver
      type: capability
      properties:
        image: ghcr.io/wasmcloud/http-server:0.22.0
      traits:
        # Compose with component to handle wasi:http calls
        - type: link
          properties:
            target: http-hello-world
            namespace: wasi
            package: http
            interfaces:
              - incoming-handler
            source_config:
              - name: listen-config
                properties:
                  ADDRESS: 127.0.0.1:8080
    # Add a capability provider that interfaces with the Redis key-value store
    - name: kvredis
      type: capability
      properties:
        image: ghcr.io/wasmcloud/keyvalue-redis:0.27.0

In this example, the kvcounter component has a link to the kvredis provider, and the httpserver provider also has a link to the component. The new link definitions are unidirectional—they have a source and a target. We no longer specify wasmCloud contracts (since those no longer exist in their previous form), and instead specify WASI interfaces. In the target_config field we can also provide configuration data that we give to a provider.

Folks in attendance were interested to explore configuration data and secrets management in more depth. Brooks and Taylor discussed how configuration data is decoupled from links themselves to facilitate more flexible secrets management, and to ensure that secrets aren't just sitting out on plaintext. Moving forward, Taylor expects the community will develop an extension to wasi:config to handle secrets in a more granular way.

First-party capability providers in ghcr and Azure​

In the past, we've used Azure registries for provider images, but there are some visibility challenges there. Today we include crates in the wasmCloud monorepo, but more importantly, you can now go to the packages section in ghcr and find all of the capability providers we distribute.

If you're looking for the latest version of the http-server, you can simply head to https://github.com/orgs/wasmCloud/packages?repo_name=wasmCloud to find it (or any other capability provider). You can reach the ghcr page quickly at https://ghcr.io/wasmcloud/wasmcloud.

Taylor asked: "Say I'm writing my own third-party provider and I want to share it with everybody. How should I do that?"

The answer: ghcr is a great solution, but anything OCI-compatible works!

Attendees suggested that it would be cool to have a centralized, searchable registry of providers for provider discovery.

One more RFC​

After some group discussion, Brooks closed his April 1st RFC for "Emoji-Based Conventional Commits" as not planned. 😢

Recording​