Provide schema for scaler configuration

[tomkerkhove]

Provide schema for scaler configuration so that we can do diffs on PRs to detect (unwanted) breaking changes, allow community to build tooling (see #249), allow platform providers to integrate and more.

This should be automatically generated based on our Go-code, or our Go-code should be linted against it.

[joebowbeer]

Provide json schema for use with kubeval or kubeconform?

[tomkerkhove]

For example, yes.

[stale]

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.

[tomkerkhove]

Any thoughts on how to do it @kedacore/keda-maintainers?

[sabbour]

Interested in this.

[tomkerkhove]

Dapr does a similar thing: https://github.com/dapr/components-contrib/blob/master/bindings/azure/servicebusqueues/metadata.yaml

We should really do this rather sooner than later as well to allow the community to build tooling for our scalers. Let me figure out how this is being generated.

[FabianTek]

Hey @tomkerkhove ,
Is there any chance this will be picked up sooner than later? I saw it on the roadmap, but what does that mean looking at the likelyhood of this being implemented?

It would really help us validating KEDA resource definitions next to basic Kubernetes resources as well as flux definitions based on their schemas

[tomkerkhove]

We need to find a way to auto-generate the schema rather than hand-crafted.

@zroubalik @JorTurFer can we do this now after doing #5797?

[JorTurFer]

I think that we will be able somehow, yes. @wozniakjan ?

[wozniakjan]

I believe so, although I haven't started working on the tooling yet.

Perhaps #5797 and the tooling can be worked on in parallel. I think when the tooling is available, it would be a great incentive for contributors to refactor the scaler config parser implementations to match #5797.

[JorTurFer]

I think that we can start with the tool indeed. I mean, we have already some scalers using this declarative approach, so we can do it right now and once there are more scalers supporting this approach, the docs should be updated "automatically"

[tomkerkhove]

I believe so, although I haven't started working on the tooling yet.

Perhaps #5797 and the tooling can be worked on in parallel. I think when the tooling is available, it would be a great incentive for contributors to refactor the scaler config parser implementations to match #5797.

Totally agree!

I think that we can start with the tool indeed. I mean, we have already some scalers using this declarative approach, so we can do it right now and once there are more scalers supporting this approach, the docs should be updated "automatically"

+1, is this something you can help with @SpiritZhou? Maybe you can collaborate with @wozniakjan on this?