Change:
return int(c.accounts[SAName].diskCount), nil } <del> // shouldInit ensures that we only init the plugin once // and we only do that in the controller func (c *BlobDiskController) shouldInit() bool { if os.Args[0] == "kube-controller-manager" || (os.Args[0] == "/hyperkube" && os.Args[1] == "controller-manager") { swapped := atomic.CompareAndSwapInt64(&initFlag, 0, 1) if swapped { return true } } return false } </del> func (c *BlobDiskController) getAllStorageAccounts() (map[string]*storageAccountState, error) { accountListResult, err := c.common.cloud.StorageAccountClient.List() if err != nil {

Discussion:
Is this a BUG REPORT or FEATURE REQUEST?: What happened: For unmanaged disk, now it is not working What you expected to happen: Works well How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Client Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.2.734+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-14T03:26:54Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"} Server Version: version.Info{Major:"1", Minor:"9+", GitVersion:"v1.9.0-alpha.2.734+", GitCommit:"", GitTreeState:"clean", BuildDate:"2017-11-14T03:26:54Z", GoVersion:"go1.9.2", Compiler:"gc", Platform:"linux/amd64"} Cloud provider or hardware configuration: OS (e.g. from /etc/os-release): RHEL7 Kernel (e.g. ): Install tools: ansible Others:
/assign andyzhangx /sig azure
I cannot reproduce your issue with v1.9.0, in your storage class, an azure disk would be provisioned in storage account , it may fail because name is already occupied, but in your case it's a strage string: . So could you also paste the controller manager log, below is the way how to get it: There should be an important log like following:
I did not run containerized k8s, I deployed a cluster by ansible: I got the controller message as below: I am quit sure there is already a storage account in its resource group which is assigned in sc's parameter: I do not know why controller does not find it and wants to create a new one. But in our subscription the storage account has reached the max number and cannot be created anymore, the error is different from this.
cc
would you add in your stroage class, and try again? In your case, is not invoked due to: I am working out a PR to fix this, as a workaround, you could try storage class like following: Let me know if that works, thx
Yes. working now with this parameter :

<!-- This form is for bug reports and feature requests ONLY! If you're looking for help check and the . --Is this a BUG REPORT or FEATURE REQUEST?: BUG /kind bug What happened: is buggy. It prevents running hyperkube from other path. In fact, it shouldn't assume the code is just running in controller master at all, especially when cloud provider is running out of tree. What you expected to happen: How to reproduce it (as minimally and precisely as possible): Anything else we need to know?: Environment: Kubernetes version (use ): Cloud provider or hardware configuration**: OS (e.g. from /etc/os-release): Kernel (e.g. ): Install tools: Others:
/assign
This code logic is to make sure the blobController only initialize once in controller-manager other than in other component, e.g. kubelet, do you have any suggestion to use similar implementation? Current design is azure pv code could only run in controller-manager.
If the idea is to exclude other components, I prefer a black list, not a broken white a list as here.
there are multiple issues with this code: It shouldn't bootstrap any storage accounts at all. This is really poor user experience. Not all users want to/will use azure disk. These storage accounts are yet created without any explicit documentation or prior warning.Even with these storage accounts, it doesn't help accelerate PV provisioning.This is the only place to init . If controller master is launched from a different path (which is usually the case), then never gets initialized, and will cause a panic when being used.
thanks for the check, put the storage accounts bootstrap in could be more appropiate: that is only when user select kind and would like to create blob disk PVC, then those accounts would be created and it would only initialize before first PVC is created.
SGTM, looking forward to your PR and 1.7/1.8 cherry picks
update: code complete, I need to do some test before sending PR:

Is this a BUG REPORT or FEATURE REQUEST?: /kind bug What happened: The azuredd plugin will always provision two instances of storage account with different type during init. There could be cases when: may only want to use one certain type of storage account, then the other type of storage account would be not in use. chooses to use managed disk, both of the storage account would be not in use. There is a limit for storage account numbers per subscription, and the storage account should be created with a on-demand policy. Log: Code: What you expected to happen: The storage accounts be created on-demand. How to reproduce it (as minimally and precisely as possible): Setup a kubernetes v1.7.2 cluster on Azure, create a dynamic pvc. Anything else we need to know?: Environment: Kubernetes version (use ):Cloud provider or hardware configuration*: Azure
/sig azure
Creating a storage account is a lengthy process (~ 1.5 mins), these 2 accounts are created upfront to ensure that PVCs will be quickly provisioned into existing storage accounts. Since ACS & acs-engine currently supports mixed (managed and blob) disks we won't be able to tell if they user will or won't use blob disks. Maybe once acs- moves away from blob disks we can disable them. They have no impact on users since users get billed only for data inside storage accounts not storage accounts themselves
for the "limit for storage account numbers per subscription" issue, I have another issue to track this: , will fix it in v1.9 and cherry pick to v1.8, v1.7
/assign