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.

Embed in runway.yml

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.