We need to ensure that when converting resource.Quantity
to int64 it does not overflow and if it does, then an error is
returned back to the use rather than attempting expansion and
provisioning operations with scaled value.
- Move from the old github.com/golang/glog to k8s.io/klog
- klog as explicit InitFlags() so we add them as necessary
- we update the other repositories that we vendor that made a similar
change from glog to klog
* github.com/kubernetes/repo-infra
* k8s.io/gengo/
* k8s.io/kube-openapi/
* github.com/google/cadvisor
- Entirely remove all references to glog
- Fix some tests by explicit InitFlags in their init() methods
Change-Id: I92db545ff36fcec83afe98f550c9e630098b3135
update bazel and fix goftm
use defaultStorageAccountKind
fix test failure
update godep license file
fix staging godeps issue
update staging godeps
fix comments, use one API call for file creation
Individual implementations are not yet being moved.
Fixed all dependencies which call the interface.
Fixed golint exceptions to reflect the move.
Added project info as per @dims and
https://github.com/kubernetes/kubernetes-template-project.
Added dims to the security contacts.
Fixed minor issues.
Added missing template files.
Copied ControllerClientBuilder interface to cp.
This allows us to break the only dependency on K8s/K8s.
Added TODO to ControllerClientBuilder.
Fixed GoDeps.
Factored in feedback from JustinSB.
use new storage account name generation method
use uuid to generate account name
change azure file account prefix
use uniqueID to generate a storage account name
fix comments
fix comments
fix comments
fix a storage account matching bug
only use UUID in getStorageAccountName func
use shorter storage account prefix for azure file
fix comments
fix comments
fix comments
fix rebase build error
rewrite CreateFileShare code logic
fix gofmt issue
fix test error
fix comments
fix a location matching bug
Automatic merge from submit-queue
Fix share name generation in azure file provisioner.
**What this PR does / why we need it**:
Azure file share name has a length limit of 63, but currently the code is using data volume's limit 75.
**Which issue this PR fixes**
With current implementation, when the cluster name is long, the resulting file share name could have a length of 75.
Also function `GenerateVolumeName` would produce double '-' when clusterName containing '-' is to be truncated.
In both cases, service would reject the creating file share request.
**Special notes for your reviewer**:
Please refer to:
https://docs.microsoft.com/en-us/rest/api/storageservices/naming-and-referencing-shares--directories--files--and-metadata#share-names
- Share names must be from 3 through 63 characters long.
- The name cannot contain two consecutive hyphens.
@rootfs @colemickens
**Release note**:
