Upgrade TriggerMetadata to an interface

[Eldarrin]

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.

[Eldarrin]

added a sample of my thinking

[zroubalik]

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.

[Eldarrin]

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.

[Eldarrin]

@zroubalik I can design something that will work with 2.x if you are interested, but happy to leave it to 3.x

[tomkerkhove]

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?

[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.

[JorTurFer]

@zroubalik ?

[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.

[stale]

This issue has been automatically closed due to inactivity.

[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.

[stale]

This issue has been automatically closed due to inactivity.

[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.