"Zero case" workload rightsizing should have consistent efficiencies and non-zero sizing recommendations

kubecost / cost-analyzer-helm-chart

Kubecost helm chart

http://kubecost.com/install

Apache License 2.0

475 stars 415 forks source link

"Zero case" workload rightsizing should have consistent efficiencies and non-zero sizing recommendations #1343

Closed kirbsauce closed 8 months ago

kirbsauce commented 2 years ago

version 1.92.0 rc-0

Describe the bug Savings, over-provisioned workloads...

Rightsizing recommendations are 0.
Efficiency #s are inconsistent.
Seeing recommendations with zero savings.

Expected behavior

I would expect these corner cases to at least have consistent efficiencies and non-zero sizing recommendations
I would expect that when the savings are zero I wouldn't be concerned with rightsizing them, rather I would address these in abandoned workloads.

Screenshots

┆Issue is synchronized with this Jira Task by Unito

dwbrown2 commented 2 years ago

@kirbsauce any chance you have a repro case here? I suspect this is happening in the back API in certain scenarios, e.g. when we have little to no data points.

cc @michaelmdresser who is in this part of the code base this week

kirbsauce commented 2 years ago

Sure @dwbrown2 , all you need to do is go to the request-sizing.html page on dogfood 1.92 RC and sort Efficiency from lowest to highest.

dwbrown2 commented 2 years ago

@michaelmdresser is this something you'd want to investigate?

dwbrown2 commented 2 years ago

@michaelmdresser do you understand what is causing this issue?

michaelmdresser commented 2 years ago

Not exactly. The current request sizing API logic is extremely entangled and sorting out an issue like this is high-effort low-reward. More consistent logic would result from pursuing the API schema v2 and I suspect writing the entirety of API v2 would take less time than untangling the behavior described in this ticket.

dwbrown2 commented 2 years ago

Ok, if you feel reasonably confident this isn't a quick win then we let's discuss time estimate for rewrite and decide if it should be a part of v1.94!

Adam-Stack-PM commented 2 years ago

@michaelmdresser @michaelmdresser Removing the v1.93 tag and adding it to the v1.94 planning doc.

Adam-Stack-PM commented 2 years ago

@michaelmdresser, Any chance this item will be fixed with your current work in progress?

michaelmdresser commented 2 years ago

The new API in https://github.com/kubecost/kubecost-cost-model/pull/923 should address most of these concerns, but that PR doesn't close this issue because there is still frontend work required to get data from the new API in front of users.

github-actions[bot] commented 9 months ago

This issue has been marked as stale because it has been open for 360 days with no activity. Please remove the stale label or comment or this issue will be closed in 5 days.

github-actions[bot] commented 8 months ago

This issue was closed because it has been inactive for 365 days with no activity.