Unable to load local supergraph schema file using the Helm chart

[kirkbrauer]

Describe the bug I am attempting to load a local supergraph schema GraphQL file using the Helm chart value, however, the file is not mounting or passing any configuration to the router executable within the container.

To Reproduce Steps to reproduce the behavior:

1. helm install apollo-router --set-file supergraphFile=supergraph-schema.graphql ./path-to-chart.
2. Wait for deployment and service to come up in Kubernetes.
3. Inspect the Apollo Router logs and see the error: The Apollo Router requires a composed supergraph schema at startup.

It appears that a ConfigMap called apollo-router-supergraph is created with the supergraph-schema.graphql file in it. However, the ConfigMap is never mounted to the container like the regular configuration one is. I do see a checksum annotation at the top of deployment.yaml, but the supergraphFile value nor it's ConfigMap is ever referenced again.

Expected behavior When I supply a supergraphFile, I expect the file to be added to a ConfigMap and mounted to the container as a volume. I also expect Apollo Router to automatically use this supergraph schema file if not managed federation options are provided. Currently, it appears that there are no facilities to mount the schema file or automatically modify the args to use it.

Output

Apollo Router v1.9.0 // (c) Apollo Graph, Inc. // Licensed as ELv2 (https://go.apollo.dev/elv2)

⚠️  The Apollo Router requires a composed supergraph schema at startup. ⚠️

👉 DO ONE:

  * Pass a local schema file with the '--supergraph' option:

      $ ./router --supergraph <file_path>

  * Fetch a registered schema from Apollo Studio by setting
    these environment variables:

      $ APOLLO_KEY="..." APOLLO_GRAPH_REF="..." ./router

      For details, see the Apollo docs:
      https://www.apollographql.com/docs/router/managed-federation/setup

🔬 TESTING THINGS OUT?

  1. Download an example supergraph schema with Apollo-hosted subgraphs:

    $ curl -L https://supergraph.demo.starstuff.dev/ > starstuff.graphql

  2. Run the Apollo Router in development mode with the supergraph schema:

    $ ./router --dev --supergraph starstuff.graphql

Process finished with exit code 0

Desktop (please complete the following information):

• OS: macOS 13.2 (arm64 and amd64)
• Version 1.9.0

[lukesiwalker]

I was wondering the same and then found this: https://github.com/apollographql/router/pull/2119/files

[kirkbrauer]

@lukesiwalker Humm, so it looks like the functionality is there, but for some reason, the volume is never being mounted in the deployment. I'm not sure why they decided that this should be a manual configuration task rather than something automatic when providing that value.

[kirkbrauer]

For us, this is critical for our development workflow because we want each dev to be able to have their own supergraph on their machine before pushing to Apollo Studio. That way they can compose a local supergraph, run our local deployment scripts and observe the entire PR they're about to submit including the supergraph changes before submitting or doing a review.

This is also useful for situations where you want to start your local cluster offline such as on an airplane or while working remotely. You should be able to at least make the router load without a network connection even if your downstream services may require one.

[thbojer]

Hi, I just got the same issue with the following command:

helm upgrade --install federation --set-file supergraphFile=schema-k8s.graphql oci://ghcr.io/apollographql/helm-charts/router --version 1.10.3 --values values.yaml

A ConfigMap federation-router-supergraph is created.

kubectl get configmap federation-router-supergraph -o yaml
apiVersion: v1
data:
  supergraph-schema.graphql: |-
    schema
      @link(url: "https://specs.apollo.dev/link/v1.0")
      @link(url: "https://specs.apollo.dev/join/v0.3", for: EXECUTION)
    {
      query: Query
      mutation: Mutation
    }
...

I solved the issue by manually adding a VolumeMount in the values.yaml.

...
extraEnvVars:
  - name: APOLLO_ROUTER_SUPERGRAPH_PATH
    value: /etc/apollo/supergraph-schema.graphql

extraVolumeMounts:
  - name: supergraph
    mountPath: /etc/apollo/supergraph-schema.graphql
    subPath: supergraph-schema.graphql

extraVolumes:
   - name: supergraph
     configMap:
       name: federation-router-supergraph

One problem with this solution is that the name of the ConfigMap is derived from the name of the helm deployment. The name of the deployment is thus linked to the values.yaml file.

[murphye]

Definitely this seems to be a half-implemented solution at this point. apollo-router-supergraph could be automatically mounted through Helm.

Here is my workaround tweaked from thbojer's example:

extraEnvVars:
  - name: APOLLO_ROUTER_SUPERGRAPH_PATH
    value: /etc/apollo/supergraph-schema.graphql

extraVolumeMounts:
  - name: supergraph
    mountPath: /etc/apollo/supergraph-schema.graphql
    subPath: supergraph-schema.graphql

extraVolumes:
   - name: supergraph
     configMap:
       name: apollo-router-supergraph