Add KEDAScalersInfo to display important information

[rickbrouwer]

Adding a new event (KEDAScalersInfo) so that important information is shown in e.g. Argo CD.
Added the deprecation info message by the cpu_memory_scaler and ibmmq_scaler.

Checklist

• I have verified that my change is according to the deprecations & breaking changes policy
• Tests have been added
• Changelog has been updated and is aligned with our changelog requirements
• Commits are signed with Developer Certificate of Origin (DCO - learn more)

Fixes #6328

[wozniakjan]

would it be possible to include these events in the TypedConfig deprecated logic?

keda/pkg/scalers/scalersconfig/typed_config.go

Line 102 in 8332446

Deprecated string

I can imagine we may want to add something like "DeprecatedEvent" parameter to model this behaviour, because iirc the "Deprecated" parameter present there will error the scaler parsing. Or maybe we change the current behaviour to not fail and throw event instead?

[rickbrouwer]

Thank you for the good feedback. In retrospect, it is indeed much better to handle this through TypedConfig. I’ve restructured it accordingly. I created a new parameter called deprecatedAnnounce. This will issue both, an info message (to maintain the 'old' behavior), and an event. This means I’ve removed the info message directly from the scaler, and it now also runs through TypedConfig, so the message only needs to be specified once.

I believe the other 'deprecated' parameter should remain in place. It makes the flow more logical.
First, there will be an announcement, typically for two releases.
After that, it can be converted to deprecated status, triggering an error. This is important because it provides the reason for the scaler's failure if the parameter is still in use.

Perhaps it would be good to set a standard, once something is truly deprecated and causes an error, we keep showing it for two releases and then remove the parameter to keep the code clean.
So in summary:

show 2 releases: deprecatedAnnounce: parameter x is deprecated and will be removed in release x
then remove the deprecatedAnnounce, then;
show 2 releases: deprecated: parameter x is deprecated, use parameter x instead
then remove deprecated tag

What are your thoughts?

[zroubalik]

Thank you for the good feedback. In retrospect, it is indeed much better to handle this through TypedConfig. I’ve restructured it accordingly. I created a new parameter called deprecatedAnnounce. This will issue both, an info message (to maintain the 'old' behavior), and an event. This means I’ve removed the info message directly from the scaler, and it now also runs through TypedConfig, so the message only needs to be specified once.

I believe the other 'deprecated' parameter should remain in place. It makes the flow more logical. First, there will be an announcement, typically for two releases. After that, it can be converted to deprecated status, triggering an error. This is important because it provides the reason for the scaler's failure if the parameter is still in use.

Perhaps it would be good to set a standard, once something is truly deprecated and causes an error, we keep showing it for two releases and then remove the parameter to keep the code clean. So in summary:

show 2 releases: deprecatedAnnounce: parameter x is deprecated and will be removed in release x then remove the deprecatedAnnounce, then; show 2 releases: deprecated: parameter x is deprecated, use parameter x instead then remove deprecated tag

What are your thoughts?

I like this :)

We should document this here: https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md

[wozniakjan]

What are your thoughts?

this is very well thought through from all angles, lgtm

[wozniakjan]

/run-e2e cpu|ibm
Update: You can check the progress here

[rickbrouwer]

I like this :)

We should document this here: https://github.com/kedacore/governance/blob/main/DEPRECATIONS.md

That seems like a good plan to me. I will document this there and offer it via a PR.

PR: kedacore/governance#121