Draft: feat(config): Add test case for per-region environment variable config.
feat(config): Add test case for per-region environment variable config.
This change is a straw-proposal to implement region specific configuration in Runway. As such, it is means to spark a conversation. At the moment this contains only a test to demonstrate the semantics, the implementation is missing.
Issue: team#233
Requirements
AI Gateway needs to configure a different Vertex AI endpoint, depending on the location in which AI Gateway is running. The Vertex AI region can currently not be derived from the Cloud Run GCP region automatically. Instead, AI Gateway needs to be able to configure a static mapping from Cloud Run GCP region to Vertex AI endpoint.
Design Principles
Backwards compatibility
The proposal is backwards compabitle by continuing to support the previous
KEY: "value"
syntax.
Single file
This design puts the configuration for all regions into a single file. We already have separate files for the "staging" and "production" environments, adding more files for additional dimensions is not scalable. Instead, this design uses a single file that is interpreted with appropriate context, such as the region. As a future step, we could reconcile the "staging" and "production" environments to use a single file, also.
No defaults
When a variable has a region-specific value, a value has to be provided for
each region. If no value exists for the region with which the file is
evaluated, the evaluation fails. This is intended to avoid accidental
misconfigurations. This also means that a value has to be present in all
regions. If necessary, we can work around this limitation by accepting a null
value in addition to strings.
Extensibility
As alluded to above, this schema is extensible. region
is a field in the if
struct, and we can easily add more dimentions, such as environment
.
Alternatives considered
Do nothing
The service can use the available region information to pick or compute a configuration value at runtime. For example, we could store a region -> value map in a JSON encoded environment variable:
# .runway/env-staging.yml
REGION_CONFIG='{"us-east1":"foo","europe-west2":"bar"}'
This is a viable work-around if users need something today. Ultimately, this effectively pushes the problem to the service owners and is not a good long-term solution. The checks discussed above would need to be reimplemented by each service, and chances are that not all check will get implemented everywhere.
runway.yml
Embed in Basically the same approach as outlined above, but add environment variables to .runway/runway*.yml
instead of .runway/env-*.yml
.
It's feasible, but I see value in differentiating between infrastructure definition and service configuration.
Use a simple (one dimensional) map
Also extend the syntax allowed in env-*.yml
, but use a much simpler region -> value map. Example:
PER_REGION:
us-east1: foo
europe-west2: bar
While this results in a much simpler syntax, it is limited to one dimension only, i.e. it is not extensible. Combining the deployment environment specific files into one file would not be possible, and other dimensions (say, for example, CPU architecture) could not be accommodated.