Request Right Sizing action created via Helm shows incorrect in UI

[oshri22004]

Kubecost Helm Chart Version

2.2.5

Kubernetes Version

1.29

Kubernetes Platform

EKS

Description

I tried to create an action of "Automated Request Sizing" via values.yaml and I'm getting weird stuff...

Steps to reproduce

1. temp-values.yaml:

clusterController:
  enabled: true
  actionConfigs:
    containerRightsize:
      workloads:
        - clusterID: cluster-one
          controllerKind: deployment
      schedule:
        start: "2024-06-16T00:00:00Z"
        frequencyMinutes: 5
        recommendationQueryWindow: "48h"
        lastModified: ""
        targetUtilizationCPU: 0.6
        targetUtilizationMemory: 0.6
global:
  prometheus:
    enabled: false
    fqdn: "http://monitoring-prometheus-server.monitoring.svc:80"

2. helm upgrade -i kubecost \                                                                                                                            
   oci://public.ecr.aws/kubecost/cost-analyzer --version 2.2.5 \
   --namespace kubecost \
   --create-namespace \
   -f temp-values.yaml \
   -f https://raw.githubusercontent.com/kubecost/cost-analyzer-helm-chart/develop/cost-analyzer/values-eks-cost-monitoring.yaml

   Expected behavior

having an action like it should be

Impact

No response

Screenshots

Logs

No response

Slack discussion

No response

Troubleshooting

• [X] I have read and followed the issue guidelines and this is a bug impacting only the Helm chart.
• [X] I have searched other issues in this repository and mine is not recorded.

[chipzoller]

By "weird stuff" are you only referring to the Schedule and Next Run values shown there? Or was there something else?

[chipzoller]

This may or may not be a Helm issue (ex., invalid values structure) so transferred to features-bugs. I confirmed the same behavior on 2.3.0-rc.5. An example values file looks like the below.

global:
  grafana:
    enabled: false
    proxy: false
clusterController:
  enabled: true
  actionConfigs:
    containerRightsize:
      workloads:
        - clusterID: cluster-one
          controllerKind: deployment
      #     namespace: my-namespace
      #     controllerName: my-controller
      # filterConfig:
      #   - filter: |
      #       namespace:"kyverno"+controllerKind:"deployment"
      schedule:
        start: "2024-06-17T15:04:05Z"
        frequencyMinutes: 120
        recommendationQueryWindow: "48h"
        lastModified: ''
        targetUtilizationCPU: 0.8
        targetUtilizationMemory: 0.8

[oshri22004]

By "weird stuff" are you only referring to the Schedule and Next Run values shown there? Or was there something else?

Yes, I'm referring to the Schedule and Next Run values, I didn't check if it works.

[oshri22004]

@chipzoller In addition to the UI, it doesn't seem to work.

[oshri22004]

Is there a way I can inspect the code for debugging and contributing?

[chipzoller]

Thanks for the report. I've confirmed the same thing and have logged it internally.

[oshri22004]

Hi @chipzoller , is there any update on the fix for this bug?

Thanks!

[chipzoller]

Yes, this is being fixed in 2.3.3 which should be available in a few days.

[oshri22004]

Hi @chipzoller, Thank you for the fixed version! I get the next error

ERR Kubescaler setup failed error="creating a Kubescaler: failed to update schedules upon startup: getting deployment '' in namespace '': resource name may not be empty" 

Im using this as the values:

This may or may not be a Helm issue (ex., invalid values structure) so transferred to features-bugs. I confirmed the same behavior on 2.3.0-rc.5. An example values file looks like the below.

global:
  grafana:
    enabled: false
    proxy: false
clusterController:
  enabled: true
  actionConfigs:
    containerRightsize:
      workloads:
        - clusterID: cluster-one
          controllerKind: deployment
      #     namespace: my-namespace
      #     controllerName: my-controller
      # filterConfig:
      #   - filter: |
      #       namespace:"kyverno"+controllerKind:"deployment"
      schedule:
        start: "2024-06-17T15:04:05Z"
        frequencyMinutes: 120
        recommendationQueryWindow: "48h"
        lastModified: ''
        targetUtilizationCPU: 0.8
        targetUtilizationMemory: 0.8

[oshri22004]

I want the action to change the request and limit of every deployment in the cluster.

[chipzoller]

Thanks for the feedback. We're checking internally.

[oshri22004]

Hi @chipzoller, Is there any update?

[chipzoller]

Yes, we've found the issue and it should be fixed in the upcoming 2.3.5.

[oshri22004]

Hi @chipzoller, Thank you for the newer version and for your amazing tool! I want to know how to write in the values.yaml for Request Right Sizing action creation that will change every deployment in the cluster. Should I change something in the values file below?

This may or may not be a Helm issue (ex., invalid values structure) so transferred to features-bugs. I confirmed the same behavior on 2.3.0-rc.5. An example values file looks like the below.

global:
  grafana:
    enabled: false
    proxy: false
clusterController:
  enabled: true
  actionConfigs:
    containerRightsize:
      workloads:
        - clusterID: cluster-one
          controllerKind: deployment
      #     namespace: my-namespace
      #     controllerName: my-controller
      # filterConfig:
      #   - filter: |
      #       namespace:"kyverno"+controllerKind:"deployment"
      schedule:
        start: "2024-06-17T15:04:05Z"
        frequencyMinutes: 120
        recommendationQueryWindow: "48h"
        lastModified: ''
        targetUtilizationCPU: 0.8
        targetUtilizationMemory: 0.8

[chipzoller]

This now works in Kubecost v2.3.5:

clusterController:
  enabled: true
  actionConfigs:
    containerRightsize:
      filterConfig:
        - filter: |
            controllerKind:"deployment"
      schedule:
        start: "2024-09-01T00:00:00Z"
        frequencyMinutes: 120
        recommendationQueryWindow: "48h"
        targetUtilizationCPU: 0.8
        targetUtilizationMemory: 0.8

Closing since this is now resolved.