The `s` to scale doesn't work with HPA

[raags]

Describe the bug
The s key allows to scale a deployment set, but when using the same with an HPA, it shows the error:

no column index for READY

I assume this is because its looking for the READY column seen in deployment set. The help shows s as a valid hot key, so it should work for the hpa as well.

To Reproduce
Steps to reproduce the behavior:

1. Go to the list of HPAs
2. Check that the help on top shows <s> to Scale
3. After pressing s see the error on the bottom

Expected behavior
s should work by giving an input box to change the min or max pod value (I thin min would make sense)

Versions (please complete the following information):

• OS: OSx
• K9s: v0.50.16
• K8s: v1.33.2

[uozalp]

Submitted a PR #3690

[derailed]

@raags Actually I think this is wrong and a side effect of (6881892).
The scale option should no be volunteered here.
The whole concept of an hpa is that scale up/down is based on metrics and load and should not be via user intervention.
Moreover scaling an hpa would result in an a defacto automatic up/down scale if the conditions warrant it.
Also what does scaling an hpa actually means? Is the intent to change min/max? If so might as well edit the hpa directly.

Or... am I missing it?

[uozalp]

@derailed I agree. HPA is metrics-based autoscaling, manual scaling defeats the purpose.

I saw the scale option appeared on HPAs and thought maybe the intent was to provide a way to quickly scale the target resource when metrics-based scaling is reacting too slowly or hovering just below target.

How should we proceed? I can update the PR to simply remove the scale option from HPAs instead of trying to scale the target?

[derailed]

@uozalp Thank you Umut!! I agree.

I think we should remove it. Looking at the offending PR tho, the problem goes deeper since any resource (excluding CRD) is going to default to scalable. Hence hpa, ingress, storageclass, etc... are going to have the scale option.
That's on me as I should have caught this earlier ;(
The pb is the fix is not trivial.
I think what we need to do here is look for interesting subresources and enhance the meta accordingly as we do for CRDs.

Would this make sense?

[raags]

@derailed Yeah, I agree scale option for HPA wouldn't make sense. Although, having a pause action for an HPA would be really useful, but HPA doesn't support it (KEDA has it, but then thats very specific to it, can could be a custom hotkey instead). Another way for HPA to pause could be by setting min and max replica the same.

[uozalp]

@derailed I've closed PR #3690 and submitted a temporary fix in #3696 that removes the faulty logic and uses a hardcoded list of scalable resources.

However, as you mentioned, the proper fix (dynamically detecting /scale subresource availability) is not trivial.