runtimeconfig

Overview ¶

package runtimeconfig provides implementations and helpers for managing Spin runtime config.

It is mostly a terrifying pile of secrets.

The core flow of rendering a Spin Runtime Config from the CRD is as follows:

1. We extract all of the config options from the spin app
2. For all of the config options we build a map of secrets and config maps this has the advantage of de-duping whole-secrets into a single reference when different keys may be re-used.
3. We fetch all of those secrets and config maps, returning an error if any are not found. (We do not currently support "optional" secrets, as there are no runtimeConfig options that would make sense to be optional).
4. We then iterate over the RuntimeConfig CRD again, with the augmented data, to finally build a `runtimeconfig.Spin` that has populated config options.

This mostly results in a lot of incredibly ugly code because we need to translate between very disparate schemas.

Spin Runtime Config is modelled using Rust `enums` for its schema, with schemas varying based on the `type` option - this isn't something that can be cleanly modelled in a Kubernetes CRD, which is where our "type plus list of options" schema comes from. i.e:

keyValueStores:
  - name: "mystore"
    type: "redis"
    options:
      - name: url
        value: "redis://localghost:9000"
  - name: "myotherstore"
    type: "sqlite"
    options:
      - name: path
        value: "/mnt/store/redis.db"

Or when sourcing a value from a secret:

keyValueStores:
  - name: "mystore"
    type: "redis"
    options:
      - name: url
        valueFrom:
         secretKeyRef:
           name: "my-secret"
           key: "redis-url"

Will render into toml that looks something like:

[key_value_store.mystore]
type = "redis"
url = "redis://localghost:9000"

[key_value_store.myotherstore]
type = "sqlite"
path = "/mnt/store/redis.db"

To maximize compatibility with different spin options + custom builds, we do very little validation of runtime config options in the operator.