Bug 1736793 - CSI: Dynamic pvc does not add events after pv created
Summary: CSI: Dynamic pvc does not add events after pv created
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: OpenShift Container Platform
Classification: Red Hat
Component: Storage
Version: 4.2.0
Hardware: Unspecified
OS: Unspecified
medium
medium
Target Milestone: ---
: 4.3.0
Assignee: Jan Safranek
QA Contact: Chao Yang
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2019-08-02 03:06 UTC by Chao Yang
Modified: 2020-01-23 11:05 UTC (History)
4 users (show)

Fixed In Version:
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-01-23 11:05:01 UTC
Target Upstream Version:
Embargoed:


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github openshift csi-external-provisioner pull 15 0 None closed Bug 1736793: UPSTREAM: 51: Send event on successful provisioning 2020-09-09 13:25:23 UTC
Red Hat Product Errata RHBA-2020:0062 0 None None None 2020-01-23 11:05:16 UTC

Description Chao Yang 2019-08-02 03:06:01 UTC
Description of problem:
Dynamic pvc does not update message info after pv created

Version-Release number of selected component (if applicable):
4.2.0-0.nightly-2019-07-31-162901

How reproducible:
Always

Steps to Reproduce:
1.Create sc
apiVersion: storage.k8s.io/v1
kind: StorageClass
metadata:
  creationTimestamp: "2019-08-01T06:01:35Z"
  name: foo
  resourceVersion: "62415"
  selfLink: /apis/storage.k8s.io/v1/storageclasses/foo
  uid: d15e81e7-b421-11e9-93cc-0ed2e0b1b106
parameters:
  csi.storage.k8s.io/provisioner-secret-name: aws-creds
  csi.storage.k8s.io/provisioner-secret-namespace: kube-system
  fsType: ext4
provisioner: ebs.csi.aws.com
reclaimPolicy: Delete
volumeBindingMode: WaitForFirstConsumer

2.Create pvc and pod
3.After pod is running, check pv is created
 oc get pvc pvc1
NAME   STATUS   VOLUME                                     CAPACITY   ACCESS MODES   STORAGECLASS   AGE
pvc1   Bound    pvc-3d25fbb1-b4ce-11e9-931e-0ed2e0b1b106   1Gi        RWO            foo            9m28s

4. oc describe pvc pvc1
Name:          pvc1
Namespace:     images
StorageClass:  foo
Status:        Bound
Volume:        pvc-3d25fbb1-b4ce-11e9-931e-0ed2e0b1b106
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: ebs.csi.aws.com
               volume.kubernetes.io/selected-node: ip-10-0-156-143.ap-northeast-1.compute.internal
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      1Gi
Access Modes:  RWO
VolumeMode:    Filesystem
Events:
  Type       Reason                Age                    From                                                                  Message
  ----       ------                ----                   ----                                                                  -------
  Normal     WaitForFirstConsumer  3m24s                  persistentvolume-controller                                           waiting for first consumer to be created before binding
  Normal     Provisioning          3m19s                  ebs.csi.aws.com_ip-10-0-156-143_15d14d37-b4ce-11e9-86e2-0a0984ebb3c2  External provisioner is provisioning volume for claim "images/pvc1"
  Normal     ExternalProvisioning  3m12s (x2 over 3m19s)  persistentvolume-controller                                           waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator
Mounted By:  mypod


Actual results:
PVC message is still "waiting for a volume xxxx"

Expected results:
PVC message should be like "Successfully provisioned volume xxx"
Master Log:

Node Log (of failed PODs):

PV Dump:

PVC Dump:

StorageClass Dump (if StorageClass used by PV/PVC):

Additional info:

Comment 1 Jan Safranek 2019-08-02 10:13:34 UTC
I agree, the provisioner should send an event when the provisioning succeeds.

Comment 5 Chao Yang 2019-09-11 01:09:06 UTC
It is passed on 4.2.0-0.nightly-2019-09-08-180038
Name:          pvc5
Namespace:     test
StorageClass:  foo
Status:        Bound
Volume:        pvc-6658876e-d430-11e9-adca-0a7e64619426
Labels:        <none>
Annotations:   pv.kubernetes.io/bind-completed: yes
               pv.kubernetes.io/bound-by-controller: yes
               volume.beta.kubernetes.io/storage-provisioner: ebs.csi.aws.com
               volume.kubernetes.io/selected-node: ip-10-0-148-192.us-east-2.compute.internal
Finalizers:    [kubernetes.io/pvc-protection]
Capacity:      1Gi
Access Modes:  RWO
VolumeMode:    Filesystem
Events:
  Type       Reason                 Age                From                                                                  Message
  ----       ------                 ----               ----                                                                  -------
  Normal     WaitForFirstConsumer   49s (x4 over 79s)  persistentvolume-controller                                           waiting for first consumer to be created before binding
  Normal     Provisioning           39s                ebs.csi.aws.com_ip-10-0-148-192_f3ca242b-d373-11e9-990a-0697a3fd0e00  External provisioner is provisioning volume for claim "test/pvc5"
  Normal     ExternalProvisioning   34s (x2 over 39s)  persistentvolume-controller                                           waiting for a volume to be created, either by external provisioner "ebs.csi.aws.com" or manually created by system administrator
  Normal     ProvisioningSucceeded  32s                ebs.csi.aws.com_ip-10-0-148-192_f3ca242b-d373-11e9-990a-0697a3fd0e00  Successfully provisioned volume pvc-6658876e-d430-11e9-adca-0a7e64619426
Mounted By:  pod6

Comment 7 errata-xmlrpc 2020-01-23 11:05:01 UTC
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-2020:0062


Note You need to log in before you can comment on or make changes to this bug.