Operator deletes graphql schema if not provided

[taylorsmithgg]

When deploying the following ApiDefinition w/apollo router, Tyk detects a schema on launch, but does not apply it.

It would be helpful to have an "auto sync" for discovered schemas instead of manually specifying them in the ApiDefinition.

After reconciliation, it will delete this schema, leaving it empty as it is not provided in the ApiDefinition.

apiVersion: tyk.tyk.io/v1alpha1
kind: ApiDefinition
metadata:
  name: router
spec:
  active: true
  name: router
  use_keyless: true
  protocol: http
  graphql:
    enabled: true
    execution_mode: proxyOnly
    version: "2"
    playground:
      enabled: true
      path: "/playground"
  proxy:
    target_url: http://apollo-router-prod.default.svc:80
    listen_path: /
    disable_strip_slash: true

Your Environment

• kubernetes
• tyk-operator version/commit: latest

[buraksekili]

Hi @taylorsmithgg, thanks for raising this!

The current problem that we have regarding auto-sync GraphQL schemas is that Kubernetes Controllers are unaware of changes happening in upstream APIs. What I mean by that is that if the upstream schema is updated, Operators cannot understand changes happening in the upstream. So, reconciliation won't happen, and the corresponding ApiDefinition cannot be updated properly because Reconciliation only happens when certain events happen on the Kubernetes cluster.

After reconciliation, it will delete this schema, leaving it empty as it is not provided in the ApiDefinition.

This is also expected because while using Tyk Operator, the source of truth is Kubernetes. So, whatever is stored in the ApiDefinition CR will be applied on Tyk. If GraphQL schema is not defined in Kubernetes, the subsequent reconciliation requests will update the corresponding ApiDefinition on Tyk and since Kubernetes does not have schema information, the reconciliation will delete schema from your ApiDefinition created on Tyk.

[taylorsmithgg]

Hi @taylorsmithgg, thanks for raising this!

The current problem that we have regarding auto-sync GraphQL schemas is that Kubernetes Controllers are unaware of changes happening in upstream APIs. What I mean by that is that if the upstream schema is updated, Operators cannot understand changes happening in the upstream. So, reconciliation won't happen, and the corresponding ApiDefinition cannot be updated properly because Reconciliation only happens when certain events happen on the Kubernetes cluster.

After reconciliation, it will delete this schema, leaving it empty as it is not provided in the ApiDefinition.

This is also expected because while using Tyk Operator, the source of truth is Kubernetes. So, whatever is stored in the ApiDefinition CR will be applied on Tyk. If GraphQL schema is not defined in Kubernetes, the subsequent reconciliation requests will update the corresponding ApiDefinition on Tyk and since Kubernetes does not have schema information, the reconciliation will delete schema from your ApiDefinition created on Tyk.

My suggestion is that the operator does not need to be aware of these changes. By not providing the schema, allow Tyk to automatically fetch and keep the upstream schema as source of truth. This would also need an option in tyk for automatic schema syncing as a toggle/option.

[buraksekili]

hi @taylorsmithgg, I was in contact with the team about your request. Thanks again for coming up with fantastic ideas.

Unfortunately, it is not possible at the moment because the API that does the schema update is not public on Tyk Dashboard. So, Tyk Operator cannot leverage this schema update API. Roughly speaking, Tyk Operator performs API calls by using Dashboard or Gateway APIs whenever certain events happen on the Kubernetes cluster. So, that's why we cannot update the schema on the fly because the corresponding API is not available as Dashboard API.

[taylorsmithgg]

hi @taylorsmithgg, I was in contact with the team about your request. Thanks again for coming up with fantastic ideas.

Unfortunately, it is not possible at the moment because the API that does the schema update is not public on Tyk Dashboard. So, Tyk Operator cannot leverage this schema update API. Roughly speaking, Tyk Operator performs API calls by using Dashboard or Gateway APIs whenever certain events happen on the Kubernetes cluster. So, that's why we cannot update the schema on the fly because the corresponding API is not available as Dashboard API.

This should be available, otherwise it severely cripples the capabilities for GQL provided by Tyk, especially in regard to any sort of CI/CD automation.

Would you recommend opening a separate issue with the Tyk Dashboard/Gateway API projects?

[caroltyk]

Closing as not a defect. The enhancement suggestions is in https://github.com/TykTechnologies/tyk-operator-internal/issues/13.