Description of problem: Found an regression with 3.7 OCP on Azure, if storage class has no set parameter of kind, the default "Shared" does not work Version-Release number of selected component (if applicable): openshift v3.7.36 kubernetes v1.7.6+a08f5eeb62 How reproducible: Always Steps to Reproduce: 1. Create a sc 2. Create a pvc to use this pvc Actual results: PVC could not be bound with error: Events: FirstSeen LastSeen Count From SubObjectPath Type Reason Message --------- -------- ----- ---- ------------- -------- ------ ------- 13s 13s 2 persistentvolume-controller Warning ProvisioningFailed Failed to provision volume with StorageClass "azure-dd": Create Storage Account: %!!(MISSING)(EXTRA string=001), error: storage.AccountsClient#Create: Failure responding to request: StatusCode=400 -- Original Error: autorest/azure: Service returned an error. Status=400 Code="InvalidDoubleEncodedRequestUri" Message="The request URI 'https://management.azure.com:443/subscriptions/xxxxxxxx/resourceGroups/openshift-qe/providers/Microsoft.Storage/storageAccounts/%!!(MISSING)(EXTRA%!s(MISSING)tring=001)?api-version=2016-12-01' is not valid, because it contains double encoding sequence '%!'(MISSING)." Expected results: PVC is bound PVC Dump: # cat azpvc-sc.yaml kind: PersistentVolumeClaim apiVersion: v1 metadata: name: azpvc annotations: volume.beta.kubernetes.io/storage-class: azure-dd spec: accessModes: - ReadWriteOnce resources: requests: storage: 1Gi StorageClass Dump (if StorageClass used by PV/PVC): # cat sc.yaml kind: StorageClass apiVersion: storage.k8s.io/v1 metadata: name: azure-dd provisioner: kubernetes.io/azure-disk parameters: skuName: Standard_LRS location: eastus storageAccount: test Additional info: Upstream issue: https://github.com/kubernetes/kubernetes/issues/55776
need to backport https://github.com/kubernetes/kubernetes/pull/55927
PR at https://github.com/openshift/ose/pull/1108
Tested on below version: openshift v3.10.0-0.46.0 kubernetes v1.10.0+b81c8f8 The azure disk works well if no "kind" parameter set. It will create a new storage account and keep using it.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHBA-2018:1816