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

The upstream PR is merged and we will do the backport to downstream branch . Marking it as POST till that is done.

Raz, can you give qe ack here ?

--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 ?

(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.

(I merged the PR manually via the github UI - we need to figure out the BZ rules integration...)

(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. :)

(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!

(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.

https://ceph-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/OCS%20Build%20Pipeline%204.3/93/

contains the fix.

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.

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.

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