Tool for Generating Trigger Schema

[SpiritZhou]

Proposal

Generating trigger metadata schema according to new declarative scaler configuration, which can be used for validation or other related improvement.

Input:
make generate-trigger-metadata-schema [--triggername][--output][--outputfile]

Output:
trigger-metadata-schemas.yaml

Trigger metadata example:

- type: kubernetes-workload
  metadatafields:
    activationValue:
        type: string
        default: "0"
    podSelector:
        type: string
    value:
        type: string
        default: "0"
- type: activemq
  metadatafields:
    activationTargetQueueSize:
      type: string
      optional: "true"
      default: "0"
    brokerName:
      type: string
      optional: "true"
    corsHeader:
      type: string
      optional: "true"
    destinationName:
      type: string
      optional: "true"
    managementEndpoint:
      type: string
      optional: "true"
    password:
      type: string
    passwordFromEnv:
      type: string
    restAPITemplate:
      type: string
      optional: "true"
    targetQueueSize:
      type: string
      optional: "true"
      default: "10"
    username:
      type: string
    usernameFromEnv:
      type: string

Use-Case

No response

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

No response

[wozniakjan]

the tricky part is that technically all metadata fields are string in the CRD definition despite the underlying type. The OpenAPI schema allows setting multiple types for a field, maybe we can leverage that in some way?
https://stackoverflow.com/questions/46472543/specifying-multiple-types-for-additionalproperties-through-swagger-openapi

We would likely need to change the map[string]string to map[string]any but this theoretically shouldn't be a breaking change.

[SpiritZhou]

Now the metadata parameters can be retrieved from the config, but there are two options in the following steps:

1. Attempt to merge the schemas to the ScaledObject schema. I've made several attempts in this direction, but there is no proper way to add them into the ScaledObjects CRD YAML. The major problem is that I can't find a way to validate the parameter combination of the trigger. I have tried using 'oneOf', but it is not working. If there is any other good approach, please let me know so that I can give it a try.
2. Save them as Trigger Metadata schema files and validate trigger metadata value on the webhook by loading these trigger metadata schemas at runtime.
   WDYT @JorTurFer @zroubalik @wozniakjan

[wozniakjan]

great findings @SpiritZhou! I think option 2 - a standalone schemas file should be sufficient. I personally would even descope the webhook and validation by kube-apiserver for now and only generate + publish the trigger schema file as part of the KEDA repository. That would already be a terrific improvement.