Description of problem: Customer is trying to attach the Azure VHD disk to the OpenShift, as docker registry. Unfortunately, the openshift is showing following errors: Mar 30 14:12:47 <node> atomic-openshift-node[2994]: E0330 14:12:47.066793 2994 kubelet_node_status.go:69] Unable to construct api.Node object for kubelet: failed to get external ID from cloud provider: compute.VirtualMachinesClient#Get: Failure responding to request: StatusCode=403 -- Original Error: autorest/azure: Service returned an error. Status=403 Code="AuthorizationFailed" Message="The client '<client_id>' with object id '<client_id>' does not have authorization to perform action 'Microsoft.Compute/virtualMachines/read' over scope '/subscriptions/<subscription_id>/resourceGroups/<LOCATION_ID>-SVT/providers/Microsoft.Compute/virtualMachines/<node>'." But it disappears and following error is shown: Mar 30 15:49:13 <node> atomic-openshift-node[15682]: E0330 15:49:13.665327 15682 nestedpendingoperations.go:253] Operation for "\"kubernetes.io/azure-disk/dockerregistry01\"" failed. No retries permitted until 2017-03-30 15:51:13.665304822 +0000 UTC (durationBeforeRetry 2m0s). Error: recovered from panic "runtime error: invalid memory address or nil pointer dereference". (err=<nil>) Call stack: The last error still occurs. Version-Release number of selected component (if applicable): OpenShift Container Platform 3.4.0 How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Not quite sure about the panic issue, but I found if there was a pod creating with a invalid disk, then create a pod with valid disk always fail $ oc version openshift v3.4.1.15 kubernetes v1.4.0+776c994 $ oc get pods NAME READY STATUS RESTARTS AGE azcaro 0/1 ContainerCreating 0 19m azrarw 0/1 ContainerCreating 0 20m azrwro 0/1 ContainerCreating 0 20m while azrwro and azrarw are using invalid disks, but azcaro is using a valid one.
After delete the pod with invalid disks, create a new pod with a valid one, this pod could be running: $ oc get pods NAME READY STATUS RESTARTS AGE azcaro 1/1 Running 0 4m $ oc exec -it azcaro sh / $ ls /mnt/azure/ 20170309 20170310 20170313 lost+found / $ exit
Due to comment 15 and comment 14 Change, this bug is fixed. Thanks
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-2017:0989