feat(runway-base): Remove the services key from default-values.yaml.

feat(runway-base): Remove the services key from default-values.yaml.

We originally allowed Runway services to define multiple sub-services in one Helm chart by using syntax like:

spec:
  services:
    frontend:
      <serviceSpec>
    backend:
      <serviceSpec>

This feature has repeated caused headaches, mostly because the list of sub-services is not known to the Provisioner, and so it can't know the final URL of the service and similar problems.

This change removes the multi-service layer, making the chart single-service only.

Changes

Runway Manifest

The services map is removed from the configuration layer. The <serviceSpec> is not directly attaches to spec:

spec:
  <serviceSpec>

Domain Names

Previously, because we had to accommodate multiple services in a single Helm chart, the needed an extra subdomain for the service, for example:

• app.ai-gateway-eks.us-east-1.aws.staging.runway.gitlab.net

This this change we can drop the lowest level component, simplifying the domain name to:

• ai-gateway-eks.us-east-1.aws.staging.runway.gitlab.net

This also means that the Runway Provisioner has all the information required to compute the domain name (e.g. for issuing TLS certificates).

Resource Names

Previously, we added the "release" (either staging or production) to the resource names, while using the Runway Service ID for the namespace. For example:

metadata:
  namespace: ai-gateway-eks
  name: app-production

This is wrong for two reasons:

1. We have separate clusters for staging and production, so the name adjustment is not needed and creates an artificial difference between the two environments.
2. Even if we wanted to deploy two instances of the same service to one cluster, we don't want them in the same namespace.

This change removes the "release" from the resource name and uses the Runway Service ID instead:

 metadata:
   namespace: ai-gateway-eks
-  name: app-production
+  name: ai-gateway-eks

This satisfies our requirements, and following the YAGNI principle we should not build anything else.

Should the need arise, we can introduce a multiDeployment: true value and add the "release" as a suffix to the namespace if set, allowing us to add this feature in a backwards compatible manner.

helm-unittest

The test cases have been updated to match the new behavior.

I have removed redundant tests from the deployment test cases, if they were already tested in the service chart.

Open Questions

1. I have created a v2 of the RunwayKubernetesService schema, because it felt like the right thing to do for a breaking change. However, I'm not convinced this is in the best interest of our users. The schema validation is probably the only code that honors the API version and is backwards compatible to v1. The Helm chart itself is definitely going to break with an old input file.

   Options:

   • Keep the API version at v1 since the Runway include is already versioned.
   • Add a check to the Helm chart that ensures API version is set to v2