Description of problem: Dynamic provisioned Block PV has an invalid field pv.spec.awsElasticBlockStore.fsType Version-Release number of selected component (if applicable): oc v3.10.10 openshift v3.10.10 kubernetes v1.10.0+b81c8f8 How reproducible: Always Steps to Reproduce: 1. Create a dynamic provisioning PVC 2. Check PV Actual results: # oc get pv pvc-7ffea288-7dd9-11e8-9dda-0eae52ce4d00 -oyaml apiVersion: v1 kind: PersistentVolume metadata: annotations: kubernetes.io/createdby: aws-ebs-dynamic-provisioner pv.kubernetes.io/bound-by-controller: "yes" pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs creationTimestamp: 2018-07-02T09:22:56Z finalizers: - kubernetes.io/pv-protection labels: failure-domain.beta.kubernetes.io/region: us-east-1 failure-domain.beta.kubernetes.io/zone: us-east-1d name: pvc-7ffea288-7dd9-11e8-9dda-0eae52ce4d00 resourceVersion: "47052" selfLink: /api/v1/persistentvolumes/pvc-7ffea288-7dd9-11e8-9dda-0eae52ce4d00 uid: 8153a884-7dd9-11e8-9dda-0eae52ce4d00 spec: accessModes: - ReadWriteOnce awsElasticBlockStore: fsType: ext4 <-------- this field should not be here volumeID: aws://us-east-1d/vol-050216667bfb5c138 capacity: storage: 1Gi claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: pvc-test namespace: openshift-node resourceVersion: "47044" uid: 7ffea288-7dd9-11e8-9dda-0eae52ce4d00 persistentVolumeReclaimPolicy: Delete storageClassName: gp2 volumeMode: Block status: phase: Bound Expected results: No fsType field in block PV definition Master Log: Node Log (of failed PODs): PV Dump: PVC Dump: # cat pvc.yaml apiVersion: v1 kind: PersistentVolumeClaim metadata: name: pvc-test spec: storageClassName: "" accessModes: - ReadWriteOnce volumeMode: Block resources: requests: storage: 1Gi StorageClass Dump (if StorageClass used by PV/PVC): Additional info:
Upstream PR: https://github.com/kubernetes/kubernetes/pull/65705
Origin PR: https://github.com/openshift/origin/pull/20327
Both PRs in #comment 1 and #comment 2 are already merged, move to QA to check whether the issue is fixed or not.
Tested on below version: openshift v3.10.87 kubernetes v1.10.0+b81c8f8 Still repro. The fix seemed to merge to 3.11 and did not back port to 3.10, are we going to fix this without 3.10 back port? If yes, Please set the correct target release and will verify again on 3.11. Thanks.
IMO it's pretty low prio bug that does not affect anything and we don't need to backport it into 3.10. Please check it's fixed in 3.11.z.
Tested on below version: openshift v3.11.57 kubernetes v1.11.0+d4cacc0 # uname -a Linux ip-172-18-4-48.ec2.internal 3.10.0-957.1.3.el7.x86_64 #1 SMP Thu Nov 15 17:36:42 UTC 2018 x86_64 x86_64 x86_64 GNU/Linux # cat /etc/redhat-release Red Hat Enterprise Linux Server release 7.6 (Maipo) # oc get pv pvc-e9719134-0295-11e9-9dd9-0e66e91de6d0 -o yaml apiVersion: v1 kind: PersistentVolume metadata: annotations: kubernetes.io/createdby: aws-ebs-dynamic-provisioner pv.kubernetes.io/bound-by-controller: "yes" pv.kubernetes.io/provisioned-by: kubernetes.io/aws-ebs creationTimestamp: 2018-12-18T07:24:11Z finalizers: - kubernetes.io/pv-protection labels: failure-domain.beta.kubernetes.io/region: us-east-1 failure-domain.beta.kubernetes.io/zone: us-east-1d name: pvc-e9719134-0295-11e9-9dd9-0e66e91de6d0 resourceVersion: "10885" selfLink: /api/v1/persistentvolumes/pvc-e9719134-0295-11e9-9dd9-0e66e91de6d0 uid: ea10c57a-0295-11e9-9dd9-0e66e91de6d0 spec: accessModes: - ReadWriteOnce awsElasticBlockStore: volumeID: aws://us-east-1d/vol-01fe2fb4e7706097e capacity: storage: 1Gi claimRef: apiVersion: v1 kind: PersistentVolumeClaim name: pvc namespace: default resourceVersion: "10879" uid: e9719134-0295-11e9-9dd9-0e66e91de6d0 persistentVolumeReclaimPolicy: Delete storageClassName: gp2 volumeMode: Block status: phase: Bound There is no fstype. 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-2019:0096