Remove deprecated field metricName from Scalers.

[OsamaNabih]

Proposal

As per the discussion here #4220
The metricName field will become optional and will be deprecated from Scalers in v2.12.
Label breaking-change should be added to this issue.

Use-Case

No response

Is this a feature you are interested in implementing yourself?

Yes

Anything else?

No response

[solsson]

#4220 says

since we introduced mechanisms to ensure the unique metrics names inside the ScaledObject

Which mechanism is this this? For example with the Prometheus scaler, I can't find any docs on how to get a more descriptive name than for example s0-prometheus-prometheus.

[zroubalik]

Please use trigger.name to optionally name your trigger. https://keda.sh/docs/2.10/concepts/scaling-deployments/#triggers

The previous metricName was confusing and used only internally.

[amirschw]

We are in the process of removing this field as a prerequisite before upgrading to 2.12 and noticed we use the same metricName field in one of our external scalers. Our current plan is to rename it, while keeping support for the existing name for the duration of the migration, but just mentioning it here to point you to the fact that this statement is not 100% accurate:

The previous metricName was confusing and used only internally.

I'd consider highlighting this in the deprecation notice, or maybe even consider excluding external scaler from the deprecation, but that might be too much.

[hatfarm]

I have a couple of concerns/question on this.

So, for the Prometheus scaler, there's no mention of using the name field to call out the specific name of the metric you're scaling on (but metricName is still used in the example).

The documentation is a bit unclear, but if we're using Name to be the name of the metric we're READING, would it also be used as the name of the metric being written by KEDA?

[zroubalik]

@hatfarm trigger.name is being used by internal KEDA metrics (Prometheus, OTEL) to identify the specific metrics of a scaler.