mirror of
https://github.com/optim-enterprises-bv/kubernetes.git
synced 2025-12-16 21:07:22 +00:00
35c3764bbb
Automatic merge from submit-queue (batch tested with PRs 66464, 66488). If you want to cherry-pick this change to another branch, please follow the instructions <a href="https://github.com/kubernetes/community/blob/master/contributors/devel/cherry-picks.md">here</a>. Avoid overflowing int64 in RoundUpSize and return error if overflow int **What this PR does / why we need it**: There are many places in plugins (some I may have missed) that we naively convert a resource.Quantity.Value() which is an int64, to an int, which may be only 32 bits long. Background, optional to read :): Kubernetes canonicalizes resource.Quantities, and from what I have seen testing creating PVCs, decimalSI is the default. If a quantity is in `decimalSI` format and its value in bytes would overflow an int64, e.g. `10E`, nothing happens. If it is in binarySI and its value in bytes would overflow an int64, e.g. `10Ei`, it is set down to 2^63-1 and there's no overflow of the field value. But there may be overflow later in the code which is what this PR is addressing. * Change `RoundUpSize` implementation to avoid overflowing `int64` * Add `RoundUp*Int` functions for use when an `int` is expected instead of an `int64`, because `int` may be 32bits and naively doing `int($INT64_VALUE)` can lead to silent overflow. These functions return an error if overflow has occurred. * Rename `*GB` variables to `*GiB` where appropriate for maximum clarity * Use `RoundUpToGiB` instead of `RoundUpSize` where possible **Which issue(s) this PR fixes** *(optional, in `fixes #<issue number>(, fixes #<issue_number>, ...)` format, will close the issue(s) when PR gets merged)*: Fixes # **Special notes for your reviewer**: please review carefully as we don't have e2e tests for most plugins! **Release note**: ```release-note NONE ``` edit: remove 'we do not need to worry about...'. yes we do, i worded that badly :))