Add SIP for target world validation #3217
Conversation
This SIP describes and motivates the functionality introduced in spinframework#2806. Signed-off-by: Till Schneidereit <[email protected]>
tschneidereit
force-pushed
the
sip-validate-target-environment
branch
from
ad2a273 to
be389fb
Compare
Signed-off-by: Till Schneidereit <[email protected]>
|
|
||
| Each entry in the list can be: | ||
| - A string that identifies an environment in the default registry (e.g., `"spin-up:3.3"`). | ||
| - A table with `registry` and `id` keys to identify an environment in a custom OCI registry. |
There was a problem hiding this comment.
We should permit wkg registry names (bare domain) here with the /.well-known/wasm-pkg/registry.json indirection.
There was a problem hiding this comment.
Alternatively we could specify a slightly different syntax that implies this lookup, like
targets = ["my.org/[email protected]"]This would look up the oci prefix at https://my.org/.well-known/wasm-pkg/registry.json and use it to construct an oci reference like ghcr.io/my-org/my-env:1.0. If we wanted to mechanically avoid conflicts between environments and regular wasm packages we could stick another substring in there e.g. ghcr.io/my-org/my-env:spin-env-1.0 or ghcr.io/my-org/spin-env/my-env:1.0 or something.
There was a problem hiding this comment.
@lann These entries point to TOML documents not WIT documents. (The TOML documents then point onward to WIT documents, which are typically wkg package references.)
There was a problem hiding this comment.
Sure; I'm suggesting that we could reuse the domain -> OCI mapping that wkg already implements to allow nicer specifications of targets from registries.
There was a problem hiding this comment.
Ah sorry thanks for the clarification
There was a problem hiding this comment.
This feels like a convenience feature we could add without breaking back compat if the feature achieves traction? Or are we sufficiently confident that other folks will be publishing environment TOMLs that we need to offer this in the first drop?
| [triggers.redis] | ||
| worlds = ["spin:up/[email protected]"] |
There was a problem hiding this comment.
This makes me wonder if we should accept e.g. { trigger_type = "redis", world = "spin:up/[email protected]" } as a valid target.
There was a problem hiding this comment.
I guess a slightly more verbose but flexible way to get the same effect would be allowing inline environment definitions. 🤷
There was a problem hiding this comment.
Or maybe the target could be just the world reference? While that wouldn't have explicit trigger types those can be sort of inferred from the manifest itself. 🤔
There was a problem hiding this comment.
@lann I am wary of that for two reasons:
- It breaks down as soon as multi-trigger-type enters play - you find yourself needing to infer which world corresponds to which trigger type. We tried that and it was terrible.
- It breaks the "I want to make sure I can deploy to..." abstraction. The goal here is for the developer to say "I want this to run on Wasmtime 35, Spin 3.2, and SpinKube 3.1." If I want to target
spin:up/[email protected], and figure out for myself whether that's compatible with SpinKube 3.1, then I have the tools to do that. The idea is to take care of "knowing which worlds a host supports" for you.
I'm not opposed to inline environments as an escape hatch, but I'd like them to be defined in the same way as other environments, and at that point I don't see a vast amount of value compared to putting them in a my-environment.toml file.
This SIP describes and motivates the functionality introduced in #2806.
Rendered