Tool for Generating Trigger Schema
Proposal
Generating trigger metadata schema according to new declarative scaler configuration, which can be used for validation or other related improvement.
Input:
make generate-scaler-schemas [--keda-version][--specify-scaler][--outputfile]
Output: scaler-metadata-schemas.yaml
Trigger metadata example:
kedaVersion: main
schemaVersion: 1
triggers:
- type: prometheus
metadata:
- name: serverAddress
type: string
- name: query
type: string
- name: queryParameters
type: string
optional: true
- name: threshold
type: string
- name: activationThreshold
type: string
optional: true
- name: namespace
type: string
optional: true
- name: customHeaders
type: string
optional: true
- name: ignoreNullValues
type: string
optional: true
default: "true"
- name: unsafeSsl
type: string
optional: true
- name: awsRegion
type: string
optional: true
canReadFromAuth: true
Use-Case
No response
Is this a feature you are interested in implementing yourself?
Yes
Anything else?
No response
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.
Now the metadata parameters can be retrieved from the config, but there are two options in the following steps:
- 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.
- 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
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.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed due to inactivity.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed due to inactivity.
So what is the status of this please?
This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 7 days if no further activity occurs. Thank you for your contributions.
This issue has been automatically closed due to inactivity.