kubernetes/pkg/cloudprovider
Kubernetes Submit Queue 35c3764bbb
Merge pull request #66464 from wongma7/round-overflow
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 :))
2018-07-24 19:03:01 -07:00
..
providers Merge pull request #66464 from wongma7/round-overflow 2018-07-24 19:03:01 -07:00
BUILD Run hack/update-bazel.sh 2018-06-22 16:22:57 -07:00
cloud.go Restore InstanceNotFound comment & logic 2018-05-26 21:54:15 -07:00
doc.go Use Go canonical import paths 2016-07-16 13:48:21 -04:00
OWNERS add @andrewsykim as pkg/cloudprovider approver 2018-06-19 15:46:51 -04:00
plugins.go Deprecate photon cloud provider 2018-05-11 13:18:05 -07:00
README.md fix broken cloud provider info urls 2017-09-27 08:49:33 -07:00

Deprecation Notice: This directory has entered maintenance mode and will not be accepting new providers. Cloud Providers in this directory will continue to be actively developed or maintained and supported at their current level of support as a longer-term solution evolves.

Overview:

The mechanism for supporting cloud providers is currently in transition: the original method of implementing cloud provider-specific functionality within the main kubernetes tree (here) is no longer advised; however, the proposed solution is still in development.

Guidance for potential cloud providers:

  • Support for cloud providers is currently in a state of flux. Background information on motivation and the proposal for improving is in the github proposal.
  • In support of this plan, a new cloud-controller-manager binary was added in 1.6. This was the first of several steps (see the proposal for more information).
  • Attempts to contribute new cloud providers or (to a lesser extent) persistent volumes to the core repo will likely meet with some pushback from reviewers/approvers.
  • It is understood that this is an unfortunate situation in which 'the old way is no longer supported but the new way is not ready yet', but the initial path is unsustainable, and contributors are encouraged to participate in the implementation of the proposed long-term solution, as there is risk that PRs for new cloud providers here will not be approved.
  • Though the fully productized support envisioned in the proposal is still 2 - 3 releases out, the foundational work is underway, and a motivated cloud provider could accomplish the work in a forward-looking way. Contributors are encouraged to assist with the implementation of the design outlined in the proposal.

Some additional context on status / direction:

  • 1.6 added a new cloud-controller-manager binary that may be used for testing the new out-of-core cloudprovider flow.
  • Setting cloud-provider=external allows for creation of a separate controller-manager binary
  • 1.7 adds extensible admission control, further enabling topology customization.