Description of problem (please be detailed as possible and provide log snippests): lib-bucket-provisioner is labeled as a 'Community' operator but also states it is 'provided by Red Hat'. Further it is required by Red Hat OpenShift Container Storage Operator which is a Red Hat operator. It does not seem appropriate for a Red Hat operator to rely on a Community operator. Version of all relevant components (if applicable): OCS Operator 4.2.1 lib-bucket-provisioner 1.0.0 OpenShift 4.3.0 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? No. Is there any workaround available to the best of your knowledge? No. Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 1 Is this issue reproducible? Yes Can this issue reproduce from the UI? Yes If this is a regression, please provide more details to justify this: Steps to Reproduce: 1. View lib-bucket-provisioner in the UI. Actual results: See that it is labeled Community. Attempt to install it and receive Community Operator prompt. Expected results: If it is provided by Red Hat and required by a Red Hat Operator it should not be labeled as a Community operator. Additional info: The ObjectBucket and ObjectBucketClaim CRD's that the OCS Operator requires are owned by lib-bucket-provisioner.
The lib-bucket-provisioner is indeed a community part, we don't have any "product" or DS build for it. And it's also being provided by red hat. It was designed with the idea that more providers can use it and be OB/OBC provisioners. I don't think we want to build a DS version of it and ship it as part of OCS.
Having this as a community operator means that when someone does a catalog build with the oc tool to mirror OCS, say for example: oc adm catalog build --insecure --appregistry-endpoint https://quay.io/cnr --appregistry-org redhat-operators --to=<registry> --auth-token="$QUAY_TOKEN" Means that OCS won't be able to install unless they also mirror community operators which exist in a separate org.
We really wish to support disconnected environments in 4.3, so probably it needs some attention/decision.
As per the discussion with Erin Boyd's team, since the OBC KEP is going to change the CRDs anyway and they are marked (or should be) as deprecated in the github repos. We will "swallow" the CRDs by the ocs-operator, just like we did for OCS 4.2. Once the KEP will be accepted and the new API will be available, we'll find a better solution for bringing the new API.
*** Bug 1807301 has been marked as a duplicate of this bug. ***
I'd just like to jump in to say that I now have a better understanding of what's going on and what needs to be resolved. To summarize my understanding: Currently OCS 4.2 "requires" the OB and OBC CRDs which are "owned" by lib-bucket-provisioner in the upstream community-operators catalog. This is also the (current) case for our internal OCS 4.3 builds. Since lib-bucket-provisioner has been deprecated and the new solution (initial KEP here: https://github.com/kubernetes/enhancements/pull/1383) won't be available in OpenShift for several months, maybe even a year or more, we want to change things so that OCS now "owns" the OB and OBC CRDs. This would temporarily introduce a dependency conflict in the OLM, since we'd have two owners of the same CRDs, but the OLM dependency resolution algorithm does make an exception: if one of the conflicting owners is in the same catalog as the requirement, that owner will be selected. Thus, we could release OCS 4.3 as owning OBs and OBCs, release a new version of OCS 4.2.x that does the same, and THEN remove lib-bucket-provisioner from the community-operators repo. With all that said, I'm comfortable moving forward with the proposed changes to the OCS 4.3 ocs-operator.
disconnected env has been moved out of 4.3. Should we move it to 4.4?
*** Bug 1811653 has been marked as a duplicate of this bug. ***
after clarification from Jose, merging this into OCS 4.3.0 is too risky for the entire release. Removing the exception flag and moving to a z release
*** Bug 1810693 has been marked as a duplicate of this bug. ***
wrong component. fixing...
re-establishing lost acks
backport PR is waiting for CI and merge
Could we have a quick description of intended solution listed here? It would help Daniel with verifying this bug, and me to evaluate whether what I see is enough to have related BZ 1810693 verified as well.
we no longer require the lib-bucket-provosioner and the OB/OBC CRDs would be owned by the ocs-operaror.
Installation of OCS 4.4 on disconnected OCP cluster passed without mirroring Community operators, lib-bucket-provosioner is not required anymore. Version: ocs-operator.v4.4.0-420.ci >> VERIFIED
Based on recent decision https://bugzilla.redhat.com/show_bug.cgi?id=1823937#c26 removal of lib bucket provisioner was reverted to unblock upgrade problems. Based on this, I'm moving this BZ back to NEW state, and asking dev team to update it's state.
Now that we removed owning the CRs from ocs-operator, this needs to wait for the next release. As discussed with Raz and Elad earlier today - moving to 4.5.
resetting acks for 4.5
We believe there was a fix in OLM to allow us to reintroduce the CRD ownership change, but that work is still WIP. We propose removing this from the blocker list and pushing it out to OCS 4.6 and maybe a 4.5 z-stream. Any objections?
You mean disconnected John? https://issues.redhat.com/browse/KNIP-1225 I think there are some workarounds, but what I understand that in 4.5 there should be again removed dependency on LBP. So if that's true than this will fix this issue and should be still be part of 4.5. Or do I miss something?
Per comment 37, I think we need this one.
@Jose, what is missing ? We saw that the BZ was fixed and backported. We provided a DS build with the ownership change and Petr has done some testing on it, so far looks promising. I've talked to Raz, and we think we should merge the ownership change in Tue (after 4.4.1 GA). Do you see a reason not to ?
I see no reason to backport it. What's the incentive? Even so, I don't know if the OLM fix that is required is in OCP 4.4. Even so, this BZ is targeting OCS 4.5, so moving this to ON_QA. A new bug should be opened for the 4.4 backport, if it is appropriate.
This BZ is on 4.5 ... we don't want to backport to OCS 4.4, but we want to fix it on OCS 4.5 Regarding OCP, according to BZ, the backport bug was VERIFIED on OCP 4.4.z Why ON_QE ? is it on the 4.5 branch?
(In reply to Jose A. Rivera from comment #34) > We believe there was a fix in OLM to allow us to reintroduce the CRD > ownership change, but that work is still WIP. If I am not mistaken, this work is complete. This is what Nimrod was referencing here: (In reply to Nimrod Becker from comment #39) > We saw that the BZ was fixed and backported. I think it was backported to 4.4 and lower. AI: Need to find the BZ / PR references... > We provided a DS build with the ownership change and Petr has done some testing on it, so far looks promising. To be very explicit, this is a custom, inofficial D/S build of OCS, with the ownership change re-applied to ocs-operator. @Petr, What version of OCP have been tested? - 4.4.z latest update? Or nightly? - 4.5 nightly? > I've talked to Raz, and we think we should merge the ownership change in Tue > (after 4.4.1 GA). Do you see a reason not to ? (In reply to Jose A. Rivera from comment #40) > I see no reason to backport it. First we need to have it back in master (ocs-operator). > What's the incentive? The motivation is to get rid of the workarounds needed for disconnected and eventually get rid of libbucket-provisioner a bit faster. > Even so, I don't know if the OLM fix that is required is in OCP 4.4. I think it is. Petr can confirm versions tested, and we need to provide the BZs. > Even so, this BZ is targeting OCS 4.5, so moving this to ON_QA. It can't be ON_QA since the patch needs to be done for master and 4.5. (moving back to assigned) > A new bug should be opened for the 4.4 backport, if it is appropriate. We are not intending to backport the owning patch to 4.4. Just to 4.5.
https://github.com/openshift/ocs-operator/pull/593 master PR to re-do the change
https://github.com/openshift/ocs-operator/pull/594 4.5 backport PR
This is merged.
no info is needed from me
Sorry to be late here Michael, I did just upgrade testing on nightly OCP 4.3, 4.4, 4.5 IIRC. From history of the jobs I sent to Nimord I see those job links: with OCP 4.4 : https://ocs4-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/qe-deploy-ocs-cluster/8907/ with OCP 4.5 : https://ocs4-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/qe-deploy-ocs-cluster/8946/ with OCP 4.3: https://ocs4-jenkins.rhev-ci-vms.eng.rdu2.redhat.com/job/qe-deploy-ocs-cluster/8947/ And upgrade was tested from 4.4.0 live to this build quay.io/rhceph-dev/ocs-olm-operator:4.4.1-obc_fix provided by Nimord/Boris that time.
Installation of OCS 4.5 on disconnected OCP cluster passed without mirroring Community operators, lib-bucket-provosioner is not required anymore. Version: ocs-operator.v4.5.0-518.ci >> 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 (Red Hat OpenShift Container Storage 4.5.0 bug fix and enhancement update), 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:3754
The needinfo request[s] on this closed bug have been removed as they have been unresolved for 1000 days