Bugzilla (bugzilla.redhat.com) will be under maintenance for infrastructure upgrades and will not be unavailable on July 31st between 12:30 AM - 05:30 AM UTC. We appreciate your understanding and patience. You can follow status.redhat.com for details.
Bug 1806419 - Pod unable to mount CephFS based PV if csi-cephfsplugin-provisioner pod is deleted during PVC creation [NEEDINFO]
Summary: Pod unable to mount CephFS based PV if csi-cephfsplugin-provisioner pod is de...
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat OpenShift Container Storage
Classification: Red Hat
Component: csi-driver
Version: 4.2
Hardware: Unspecified
OS: Unspecified
unspecified
medium
Target Milestone: ---
: OCS 4.3.0
Assignee: Madhu Rajanna
QA Contact: Jilju Joy
URL:
Whiteboard:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2020-02-24 07:17 UTC by Sidhant Agrawal
Modified: 2020-04-14 09:48 UTC (History)
10 users (show)

Fixed In Version:
Doc Type: No Doc Update
Doc Text:
Clone Of:
Environment:
Last Closed: 2020-04-14 09:45:56 UTC
Target Upstream Version:
madam: needinfo? (jrivera)


Attachments (Terms of Use)


Links
System ID Private Priority Status Summary Last Updated
Github ceph ceph-csi pull 840 0 None closed check subvolume present in backend 2020-08-21 17:03:39 UTC
Github openshift ceph-csi pull 3 0 None closed BUG 1806419: check subvolume present in backend 2020-08-21 17:03:39 UTC
Red Hat Product Errata RHBA-2020:1437 0 None None None 2020-04-14 09:48:16 UTC

Comment 11 Madhu Rajanna 2020-03-04 08:44:19 UTC
sagrawal can you please provide the exact steps to reproduce the issue instead of mentioning the test case to run.

it will be difficult for the developer to reproduce the issue without exact steps

Comment 13 Humble Chirammal 2020-03-04 08:54:38 UTC
The upstream PR is merged and we will do the backport to downstream branch . Marking it as POST till that is done.

Comment 16 Humble Chirammal 2020-03-04 09:17:51 UTC
Raz, can you give qe ack here ?

Comment 18 Humble Chirammal 2020-03-04 10:50:23 UTC
--snip--
@humblec: This pull request references Bugzilla bug 1806419, which is invalid:

    expected the bug to target the "4.3.z" release, but it targets "OCS 4.3.0" instead
    expected Bugzilla bug 1806419 to depend on a bug targeting the "4.4.0" release and in one of the following states: VERIFIED, RELEASE_PENDING, CLOSED (ERRATA), but no dependents were found

--/snip--

Not sure why the openshift bot on OCS bz check fails with above error. 

Boris, anythoughts here ?

Comment 20 Michael Adam 2020-03-04 14:34:20 UTC
(In reply to Humble Chirammal from comment #18)
> --snip--
> @humblec: This pull request references Bugzilla bug 1806419, which is
> invalid:
> 
>     expected the bug to target the "4.3.z" release, but it targets "OCS
> 4.3.0" instead
>     expected Bugzilla bug 1806419 to depend on a bug targeting the "4.4.0"
> release and in one of the following states: VERIFIED, RELEASE_PENDING,
> CLOSED (ERRATA), but no dependents were found
> 
> --/snip--
> 
> Not sure why the openshift bot on OCS bz check fails with above error. 
> 
> Boris, anythoughts here ?

That's nothing to do with the build team.
This is *upstream* CI.
You seem to have enabled the openshift branch protection.
But our releases which are lagging behind ocp in numbering can't use the very same criteria:
In this case, since OCP 4.3.0 is released, having a BZ for 4.3.0 is invalid. It can at most be a BZ for 4.3.z. and it has to depend on a BZ for OCP 4.4.0 that is already verified. To make sure we are fixing newer releases...

So this does not fit our OCS 4.3 state.
We had the same problem in ocs-operator and the ocp team lifted a few restrictions.
@Jose may give you the right pointers.

Comment 22 Michael Adam 2020-03-04 21:43:32 UTC
(I merged the PR manually via the github UI - we need to figure out the BZ rules integration...)

Comment 23 Humble Chirammal 2020-03-05 04:51:53 UTC
(In reply to Michael Adam from comment #20)
> (In reply to Humble Chirammal from comment #18)
> > --snip--
> > @humblec: This pull request references Bugzilla bug 1806419, which is
> > invalid:
> > 
> >     expected the bug to target the "4.3.z" release, but it targets "OCS
> > 4.3.0" instead
> >     expected Bugzilla bug 1806419 to depend on a bug targeting the "4.4.0"
> > release and in one of the following states: VERIFIED, RELEASE_PENDING,
> > CLOSED (ERRATA), but no dependents were found
> > 
> > --/snip--
> > 
> > Not sure why the openshift bot on OCS bz check fails with above error. 
> > 
> > Boris, anythoughts here ?
> 
> That's nothing to do with the build team.
> This is *upstream* CI.
> You seem to have enabled the openshift branch protection.
> But our releases which are lagging behind ocp in numbering can't use the
> very same criteria:
> In this case, since OCP 4.3.0 is released, having a BZ for 4.3.0 is invalid.
> It can at most be a BZ for 4.3.z. and it has to depend on a BZ for OCP 4.4.0
> that is already verified. To make sure we are fixing newer releases...
> 
> So this does not fit our OCS 4.3 state.
> We had the same problem in ocs-operator and the ocp team lifted a few
> restrictions.
> @Jose may give you the right pointers.

Sure, from the error itself I got the issue or in simple terms, its validating against 
OCP bugzillas being Openshift prow. What I was trying to figure out here was, as the bugzilla
check happens from Prow, either the bugzilla check should not worry if the bugzilla is not in "OCP"
component or it should have a different validation criteria for components other than OCP as in this case. :)

Comment 24 Humble Chirammal 2020-03-05 04:52:37 UTC
(In reply to Michael Adam from comment #22)
> (I merged the PR manually via the github UI - we need to figure out the BZ
> rules integration...)

Thanks Michael!

Comment 25 Michael Adam 2020-03-05 19:58:42 UTC
(In reply to Humble Chirammal from comment #23)
> (In reply to Michael Adam from comment #20)
> > (In reply to Humble Chirammal from comment #18)
> > > --snip--
> > > @humblec: This pull request references Bugzilla bug 1806419, which is
> > > invalid:
> > > 
> > >     expected the bug to target the "4.3.z" release, but it targets "OCS
> > > 4.3.0" instead
> > >     expected Bugzilla bug 1806419 to depend on a bug targeting the "4.4.0"
> > > release and in one of the following states: VERIFIED, RELEASE_PENDING,
> > > CLOSED (ERRATA), but no dependents were found
> > > 
> > > --/snip--
> > > 
> > > Not sure why the openshift bot on OCS bz check fails with above error. 
> > > 
> > > Boris, anythoughts here ?
> > 
> > That's nothing to do with the build team.
> > This is *upstream* CI.
> > You seem to have enabled the openshift branch protection.
> > But our releases which are lagging behind ocp in numbering can't use the
> > very same criteria:
> > In this case, since OCP 4.3.0 is released, having a BZ for 4.3.0 is invalid.
> > It can at most be a BZ for 4.3.z. and it has to depend on a BZ for OCP 4.4.0
> > that is already verified. To make sure we are fixing newer releases...
> > 
> > So this does not fit our OCS 4.3 state.
> > We had the same problem in ocs-operator and the ocp team lifted a few
> > restrictions.
> > @Jose may give you the right pointers.
> 
> Sure, from the error itself I got the issue or in simple terms, its
> validating against 
> OCP bugzillas being Openshift prow. What I was trying to figure out here
> was, as the bugzilla
> check happens from Prow, either the bugzilla check should not worry if the
> bugzilla is not in "OCP"
> component or it should have a different validation criteria for components
> other than OCP as in this case. :)

No, the check is not for bugs on the OCP product. It is mainly about the target versions and certain BZ states expected.

Comment 27 Jilju Joy 2020-03-10 15:25:30 UTC
The test case test_pvc_disruptive[CephFileSystem-create_pvc-cephfsplugin_provisioner] passed in 

1. https://ocs4-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/qe-deploy-ocs-cluster/5188/ (AWS-IPI)

ocs-operator.v4.3.0-363.ci
cephcsi@sha256:494e491818dcdcc030c0dbbf7f7f45a019a51abf7b34d17e9b06b82c38d9e17d

 
2. local run (VMWARE)

ocs-operator.v4.3.0-372.ci
cephcsi@sha256:676beaf8f390331d8c5d65a2aa3cb3b38488cdd88949e56ae1ffde61fd31a5d7


3. Manual (VMWARE)
ocs-operator.v4.3.0-372.ci
cephcsi@sha256:676beaf8f390331d8c5d65a2aa3cb3b38488cdd88949e56ae1ffde61fd31a5d7


Considering the fact that the test was not always failing previously and the probability of hitting this issue is less, we will wait for some more iterations in automation run before moving this to verified state.

Comment 28 Jilju Joy 2020-03-12 14:43:08 UTC
Executed more iterations of test_pvc_disruptive[CephFileSystem-create_pvc-cephfsplugin_provisioner]

1. Local run - Passed all 5 iterations
ocs-operator.v4.3.0-372.ci
cephcsi@sha256:676beaf8f390331d8c5d65a2aa3cb3b38488cdd88949e56ae1ffde61fd31a5d7

2. Jenkins https://ocs4-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/qe-deploy-ocs-cluster/5388/
ocs-operator.v4.3.0-372.ci
cephcsi@sha256:676beaf8f390331d8c5d65a2aa3cb3b38488cdd88949e56ae1ffde61fd31a5d7


Based on the results (also from #Comment27), marking this as verified.

Comment 32 errata-xmlrpc 2020-04-14 09:45:56 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:1437


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