You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently, the spin-shim imposes rigid preferences on the instantiation of the spin runtime. For instance, it starts spin on port 80 without any provision for configuration.
There exist several valuable spin up flags that could be applicable, even in Kubernetes environments. Some of these flags include:
Here are some flag options that are currently unavailable:
--direct-mounts
Description: When dealing with local applications featuring directory mounts and no excluded files, this option allows for direct mounting instead of utilizing a temporary directory.
Current State: The direct-mounts feature is not active, which limits the functionality of certain sidecar scenarios (e.g., sharing ephemeral volumes). It should be made optional.
--runtime-config-file <RUNTIME_CONFIG_FILE>
Description: This flag specifies a configuration file for config providers and Wasmtime config.
Current State: The absence of this option prevents the utilization of dynamic runtime configuration features of spin. Specifically, it hinders the use of Vault secrets or Redis as a substitute for the Spin-Internal KV-store.
Additional intriguing spin up flags may include <FOLLOW_ID> or <KEY_VALUES>.
Feature Request
The request is to empower users to leverage spin's configuration options, ideally through the use of environment variables.
One particularly interesting option is <ENV>, as the shim would need to differentiate between environment variables intended for the runtime and those meant for the spin application.
-e, --env <ENV>
Description: This flag allows for passing an environment variable (in the form of key=value) to all components of the application.
We therefore possibly would need to namespace env vars for runtime configuration.
I'm eager to hear about your opinion!
The text was updated successfully, but these errors were encountered:
Problem Description
Currently, the spin-shim imposes rigid preferences on the instantiation of the spin runtime. For instance, it starts spin on port 80 without any provision for configuration.
There exist several valuable
spin up
flags that could be applicable, even in Kubernetes environments. Some of these flags include:Here are some flag options that are currently unavailable:
--direct-mounts
--runtime-config-file <RUNTIME_CONFIG_FILE>
Additional intriguing
spin up
flags may include<FOLLOW_ID>
or<KEY_VALUES>
.Feature Request
The request is to empower users to leverage
spin
's configuration options, ideally through the use of environment variables.One particularly interesting option is
<ENV>
, as the shim would need to differentiate between environment variables intended for the runtime and those meant for the spin application.-e, --env <ENV>
We therefore possibly would need to namespace env vars for runtime configuration.
I'm eager to hear about your opinion!
The text was updated successfully, but these errors were encountered: