velaux 1.9.1 Configure the gateway, and convert the port into a string

[Louse-luo]

Describe the bug

velaux 1.9.1 Configure the gateway, and convert the port into a string
To Reproduce

cannot generate manifests from components and traits: evaluate template trait=gateway app=third-app1-prod: invalid template of trait gateway after merge with parameter and context: outputs.service.spec.ports.0.port: conflicting values "8090" and int (mismatched types string and int) (and 3 more errors)
Expected behavior

Screenshots

KubeVela Version
1.9.1

Cluster information

Additional context

[chivalryq]

Could you provide a screenshot?

[Kolossi]

@Louse-luo : please provide an example manifest which fails, thanks.

[wonderflow]

Same issue reported in Dingtalk, I'm copy-paste the screenshoots here:

[Kolossi]

thanks @wonderflow do we know the last version where this didn't happen?

and can you publish a full repro for getting to this state shown in the screenshot?

[wonderflow]

@Kolossi Thanks Paul for investigating this issue. The reporter didn't send the full repro, so I can't provide that.

I checked the gateway trait:

https://github.com/kubevela/kubevela/blob/v1.9.2/vela-templates/definitions/internal/trait/gateway.cue#L149

It's defined as http: [string]: int in CUE, AFAIK, the port must be a int, why it become a string in this case?

[Kolossi]

Indeed, I looked and saw the same.

Also, my changes to gateway were included in v1.9.0 and doing a diff to previous 1.8.2, there's nothing changed around port - v1.8.2...v1.9.1#diff-eb6e43f0e2cf800a96e1dac66f3f4871067f865d5c694d9efa5c84cb2529a5a0

Is there something hardcoded in velaux about ports which has broken (again I tried a github search and couldn't find anything).

🤔

[wonderflow]

ping @chivalryq @barnettZQG , will it possible that's a bug caused by velaux?

[chivalryq]

I will dig into this recently.

[lxkaka]

same problem in 1.9.1； now we degrade to 1.8.1 ; keep an eye on this

[Kolossi]

@lxkaka : can you post the steps to reproduce this issue please

[barnettZQG]

Let's check the open API schema that generate from the gateway trait, it save in a configmap. @chivalryq

[lxkaka]

@Kolossi

in 1.9.1 the port will be render to "8888" in yaml

[Kolossi]

@chivalryq I really can't see anything in either kubevela or velaux diff between 1.8.1 and 1.9.1. Perhaps it's a change in the underlying cue version that has changed the behaviour? I'm going to have to leave this with you.

[chivalryq]

@Kolossi No worry. Will take care of this.

[chivalryq]

I try to repro with:
velaux: v1.9.1, run the server locally.
vela-core v1.9.3
gateway trait: master.

When creating trait, velaux send the request to apiserver with the value of string type.

[chivalryq]

OpenAPI schema is like below. It's like there's something wrong in grammar. Still investigating.

{
  "properties": {
    "class": {
      "default": "nginx",
      "description": "Specify the class of ingress to use",
      "title": "class",
      "type": "string"
    },
    "classInSpec": {
      "default": false,
      "description": "Set ingress class in ''.spec.ingressClassName'' instead of ''kubernetes.io/ingress.class'' annotation.",
      "title": "classInSpec",
      "type": "boolean"
    },
    "domain": {
      "description": "Specify the domain you want to expose",
      "title": "domain",
      "type": "string"
    },
    "gatewayHost": {
      "description": "Specify the host of the ingress gateway, which is used to generate the endpoints when the host is empty.",
      "title": "gatewayHost",
      "type": "string"
    },
    "http": {
      "additionalProperties": {
        "type": "integer"
      },
      "description": "Specify the mapping relationship between the http path and the workload port",
      "title": "http",
      "type": "object"
    },
    "secretName": {
      "description": "Specify the secret name you want to quote to use tls.",
      "title": "secretName",
      "type": "string"
    }
  },
  "required": [
    "http",
    "class",
    "classInSpec" [],
    "type"
    :
    "object"
    }

[lxkaka]

@chivalryq we will keep an eye on this

[chivalryq]

Openapi schema is not wrong. It's a k9s bug.