Kyma APIRule v2alpha1: MaxAge default causing an error in Terraform

[SeanKilleen]

Hi all,

I'm working to migrate my existing entries for APIRule v1beta1 to v2alpha1, and I've hit upon something that I think might be an issue with the default manifest coming from Terraform.

Below is my original version of the v1beta1 rule in our Terraform (since it's just a manifest it should map to the YAML directly):

resource "kubernetes_manifest" "api_gateway_seq" {
  depends_on = [
    kubernetes_namespace_v1.o11y, data.kubernetes_service_v1.grafana_service, kubernetes_namespace_v1.dns_management,
    kubernetes_manifest.istio_gateway
  ]
  for_each = local.gateways

  manifest = {
    apiVersion = "gateway.kyma-project.io/v1beta1"
    kind       = "APIRule"
    metadata = {
      name      = "seq-apigateway-https-${each.value.suffix}"
      namespace = kubernetes_namespace_v1.o11y.metadata[0].name
    }
    spec = {
      gateway = each.value.gateway
      host = "seq.${each.value.host}"
      service = {
        name = data.kubernetes_service_v1.seq.metadata[0].name
        port = 80
      }

      rules = [{
        path    = "/.*"
        methods = ["GET", "POST", "PUT", "DELETE"]
        accessStrategies = [{
          handler = "allow"
          config  = {}
        }]
      }]
    }
  }
}

And below are the modifications I've made to support v2alpha1 --

• Updated "host" to "hosts" with an array of 1
• Added namespace to service
• Added noAuth = true

resource "kubernetes_manifest" "api_gateway_seq" {
  depends_on = [
    kubernetes_namespace_v1.o11y, data.kubernetes_service_v1.grafana_service, kubernetes_namespace_v1.dns_management,
    kubernetes_manifest.istio_gateway
  ]
  for_each = local.gateways # we have multiple gateways

  manifest = {
    apiVersion = "gateway.kyma-project.io/v2alpha1"
    kind       = "APIRule"
    metadata = {
      name      = "seq-apigateway-https-${each.value.suffix}"
      namespace = kubernetes_namespace_v1.o11y.metadata[0].name
    }
    spec = {
      gateway = each.value.gateway

      hosts = ["seq.${each.value.host}"]

      service = {
        name      = data.kubernetes_service_v1.seq.metadata[0].name
        namespace = data.kubernetes_service_v1.seq.metadata[0].namespace
        port      = 80
      }

      rules = [{
        path    = "/.*"
        methods = ["GET", "POST", "PUT", "DELETE"]
        noAuth  = true
      }]
    }
  }
}

 However, when I attempt to apply the Terraform, I see:

> AttributeName("maxAge"): can't use tftypes.String as tftypes.Number

I can't find any reference to maxAge in any default YAML files I've seen, but it does seem like it factors into corsPolicy.

Is there an appropriate default I should be moving to here? Or is this an issue with the standard resource definition?

[bchwila]

Hi Sean, Unfortunately I was not able to reproduce the same behaviour when doing the same using kubectl (with server side apply, to mirror Terraform behaviour). Could you please provide some more verbose logs from the Terraform apply?

[SeanKilleen]

@bchwila thanks for responding! Something that wasn't clear to me -- is the intent that I should be able to run this upgrade as-is, or should I be running an import into the v2alpha1 resource for what's actually there? My impression from all the blog posts was that I'd be able to do this without needing to import the existing resource again. I apologize that it appears I missed a bit of crucial context! The error I see is on Terraform plan, I see "Error: Failed to update proposed state from prior state" in addition to the "AttributeName("maxAge"): can't use tftypes.String as tftypes.Number" error.

[SeanKilleen]

I think this has something to do with a message I'm seeing in the Kyma UI: "Disabling custom CORS Policy is not recommended. Consider setting up CORS yourself". So it looks ilke we might be an edge case in that regard. I'll just go the standard route and set up CORS policy in this case I think, prior to converting.

[SeanKilleen]

Ultimately, this seemed to be an edge case caused by the fact that we hadn't yet defined a CORS policy for this APIRule in the v1 structure.

What was ultimately successful for us to move to a v2alpha1 rule in our setup was:

• Update apiVersion to v2alpha1
• Change host to hosts and make into an array
• Add namespace to the service object
• Update path from /.* to /* -- this was a bit of a surprise but the error messages were helpful enough.
• Add noAuth = true
• Add a corsPolicy object

We could choose to add a corsPolicy object in our v1 resources or as part of v2. I extracted a default policy and applied that in our Terraform while moving to v2alpha1.