kedacore/keda

Add support for templating in `spec.triggers.metadata.query`

Open

#2,757 opened on Mar 14, 2022

View on GitHubContributor guide
 (9 comments) (4 reactions) (0 assignees)Go (1,457 forks)auto 404
featurehelp wanted

Repository metrics

Stars
 (10,372 stars)
PR merge metrics
 (PR metrics pending)

Description

Proposal

It'd be great if Keda allowed users to use templates instead of hardcoding the target deployment name in the query when using a scaler like Prometheus. Something along the lines of:

triggers:
  - type: prometheus
    metadata:
      serverAddress: http://<prometheus-host>:9090
      metricName: http_requests_total
      threshold: '100'
      query: sum(rate(http_requests_total{deployment="{{ target-deployment }}"}[2m]))

Keda could then refer to .spec.scaleTargetRef to get the actual value and insert it into the query before running the query. This would enable other operators to interact with ScaledObjects in a cleaner manner.

Use-Case

This would help a controller in creating a ScaledObject for a deployment based on an existing user provided ScaledObject for a different deployment. Right now, copying over the spec of the existing ScaledObject (and inherently the query for the scaler) would lead to the new ScaledObject to scale based on the query meant for the other deployment. This would force some kind of a best effort attempt at modifying the query suitable for the new ScaledObject, which is error prone. Adding support for templates, makes it easier for controllers by letting them just copy pasting the spec and eliminates the need for any hacky query modification.

Anything else?

No response

Contributor guide

Research direction
Explore how scalers like Prometheus parse their metadata.query. Look for a common interface or pattern used to pass query strings to scalers. Then implement a template engine (e.g., using Go's text/template) to substitute placeholders like {{ target deployment }} with the corresponding value from spec.scaleTargetRef. Ensure that the substitution happens before the query is executed. Consider adding a new function or modifying the existing scaler initialization to support templating. Test with multiple scalers.
Tech stack
go
Domain
clouddevopsbackend
Issue type
Feature
DifficultyEstimated implementation difficulty for a new contributor, from 1 for very small changes to 5 for expert-level work.
3
Estimated timeA rough time range for an experienced contributor to investigate, implement, test, and prepare a pull request.
1-2 days
Activity statusHow available the issue appears right now: fresh, active, stale, blocked, or waiting on maintainer input.
Active
ClarityHow clearly the issue explains the expected change, acceptance criteria, and next step.
Clear
Prerequisites
GoKubernetesKEDA
Newbie friendlinessA 1-100 score estimating how approachable this issue is for first-time contributors.
30