keda
keda copied to clipboard
Upgrade TriggerMetadata to an interface
Proposal
I've noticed when writing scalers I need to use TriggerMetadata (map[string]string) which just give KVPs. However I end up using arrays so just end up with comma separated strings. This makes charts etc for deploying scalers harder.
Could we add a new TriggerMetadata to an interface or similar so that arrays can be actual arrays in the manifests when deploying scaler instances?
example:
TriggerMetadata:
demands: "test,test1,test2"
vs:
demands:
- test
- test1
- test2
Use-Case
Easier management of actual scalers through helm etc, especially when using a lot of them.
Is this a feature you are interested in implementing yourself?
Maybe
Anything else?
I can do it, but I suspect some design thought is needed here first.
added a sample of my thinking
Yeah, the initial decision behind TriggerMetadata structure is not ideal. It would be much better if we use a different approach. For example the one you proposed.
My only concern is backwards compatibility.
Well the only way to maintain backwards is to add a new variable to the scalerconfig or we need to rewrite every scaler to match. Don't see another way.
@zroubalik I can design something that will work with 2.x if you are interested, but happy to leave it to 3.x
Stupid question - Why can't we introduce a new API version that uses this new design? Implementation wide input scheme of TriggerAuth should be decouple from how scalers use that info, no?
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.
@zroubalik ?
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.
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.