A kubectl plugin for listing scaling events

[26tanishabanik]

Proposal

A simple kubectl plugin which will list the current scaling events under the deployed keda replicas.

Examples:

kubectl get scaling-events

Output:
NameOfScaler                           Scaling decision
couchdb-scaler                         no of rows greater than threshold
loki-scaler                            metric value greater than a threshold

What do you guys think?
I would be glad to pick this up as soon as this issue receives any positive feedback from the community.

Use-Case

Show the different scaling events of different scalers listed under the keda operator

Anything else?

No response

[zroubalik]

Do you think this use case is worth implementing?

[26tanishabanik]

Do you think this use case is worth implementing?

I think it is, in context that, suppose I would want to know as an user what scalers are available in my cluster currently or the scaling events which are driving the auto scalers or scaling different resources, just using kubectl only

[neelanjan00]

Do you think this use case is worth implementing?

I think it is, in context that, suppose I would want to know as an user what scalers are available in my cluster currently or the scaling events which are driving the auto scalers or scaling different resources, just using kubectl only

Since scalers are defined as part of ScaledJobs/ScaledObjects triggers, I think it will be worth it if we can list them, the trigger(s) that they are using, and the parameter config of the triggers.

[zroubalik]

Well yeah, but it is not so straighforward to query for this info from KEDA. You will need to manage all of that in the plugin seaprately (which si fine for the list of scalers, but might be a painful process when listing config options per scaler (it is a huge number)).

[26tanishabanik]

Do you think this use case is worth implementing?

I think it is, in context that, suppose I would want to know as an user what scalers are available in my cluster currently or the scaling events which are driving the auto scalers or scaling different resources, just using kubectl only

Since scalers are defined as part of ScaledJobs/ScaledObjects triggers, I think it will be worth it if we can list them, the trigger(s) that they are using, and the parameter config of the triggers.

Agreed, that way it will be easier to view all the triggers @neelanjan00

[26tanishabanik]

Well yeah, but it is not so straighforward to query for this info from KEDA. You will need to manage all of that in the plugin seaprately (which si fine for the list of scalers, but might be a painful process when listing config options per scaler (it is a huge number)).

That will also be a long list, true @zroubalik , what do you suggest?

[neelanjan00]

Well yeah, but it is not so straighforward to query for this info from KEDA. You will need to manage all of that in the plugin seaprately (which si fine for the list of scalers, but might be a painful process when listing config options per scaler (it is a huge number)).

That's a valid concern, I think. We can have a verbose flag for listing the config options maybe. Otherwise it might be done on a per ScaledJob/ScaledObject basis rather than for all of them at once.

[tomkerkhove]

I think writing them to our SO/SJ resources would be better: #3764

[zroubalik]

@26tanishabanik @neelanjan00 scalers are not defined on the ScaledObject/Job level, there are just metadata (map[string]string) that needs to be validated for each scaler. So it is not easy (possible) to programatically list all the options.

For example:

keda/pkg/scalers/activemq_scaler.go

Line 77 in 4148769

func parseActiveMQMetadata(config *ScalerConfig) (*activeMQMetadata, error) {

[zroubalik]

I think writing them to our SO/SJ resources would be better: #3764

I don't think I follow.

[26tanishabanik]

@26tanishabanik @neelanjan00 scalers are not defined on the ScaledObject/Job level, there are just metadata (map[string]string) that needs to be validated for each scaler. So it is not easy (possible) to programatically list all the options.

For example:

keda/pkg/scalers/activemq_scaler.go

Line 77 in 4148769

func parseActiveMQMetadata(config *ScalerConfig) (*activeMQMetadata, error) {

Can't we just define a parameter in keda itself to define what the event is, and then fetch it? @zroubalik

[tomkerkhove]

I think writing them to our SO/SJ resources would be better: #3764

I don't think I follow.

#3764 (comment) should clarify this, but basically give insights to how your SO/SJ is doing and when it has last scaled

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