Description of problem ====================== Currently, for the obc-metrics-collector is prerequisite to have cephobjectstoreuser with name "prometheus-user" with certain permissions. It is better to automate that workflow than doing it manually Version of all relevant components =================================== 4.9 Does this issue impact your ability to continue to work with the product ======================================================================== Is there any workaround available to the best of your knowledge? ================================================================ Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? ======================================== Can this issue reproducible? ============================ Yes Can this issue reproduce from the UI? ===================================== Yes If this is a regression ======================= Additional info =============== For adding permissions to user the following PR https://github.com/rook/rook/pull/8211 in Rook needs to merge Post that small fix OCS-Op to create that user. Fix is not intrusive for any existing workflow.
The dependent Rook PR got merged in v1.7.3 and OCS-Op PR posted https://github.com/red-hat-storage/ocs-operator/pull/1336
This is not ready for 4.9, moving it to 4.10 For 4.9, we have opened a doc BZ (#2015382) to document the procedure.
(In reply to Mudit Agarwal from comment #11) > This is not ready for 4.9, moving it to 4.10 > For 4.9, we have opened a doc BZ (#2015382) to document the procedure. Per comment 3, this is not acceptable as long as RHSTOR-1879 is not pushed out as well. Moreover we are going to receive this via upstream rebase anyway, so I would like to see how would we handle that exactly no matter which decision will be taken in the end. Please consult next steps with QE owner of RHSTOR-1879, until that happens, I'm moving it back. One sided override like that is simply not acceptable. Please not do it again.
Status of this BZ is disputed, and decision needs to be based on both QE and DEV owners of this bug and RHSTOR-1879.
(In reply to Martin Bukatovic from comment #14) > (In reply to Mudit Agarwal from comment #11) > > This is not ready for 4.9, moving it to 4.10 > > For 4.9, we have opened a doc BZ (#2015382) to document the procedure. > > Per comment 3, this is not acceptable as long as RHSTOR-1879 is not pushed > out as well. > Moreover we are going to receive this via upstream rebase anyway, so I would > like to see how would we handle that exactly no matter which decision will > be taken in the end. We are not going to receive the complete fix via upstream, only rook fix is in upstream. If we were able to fix this within the dev freeze time, then it would not have moved. > Please consult next steps with QE owner of RHSTOR-1879, until that happens, > I'm moving it back. One sided override like that is simply not acceptable. > Please not do it again. This is a dev preview feature, which means regression only. Moreover, this is not a blocker and thus doesn't qualify after we enter dev freeze. If you want to see this in 4.9, please mark it a blocker with proper justification saying why we should not release 4.9 without this fix.
(In reply to Mudit Agarwal from comment #21) > We are not going to receive the complete fix via upstream, only rook fix is > in upstream. > If we were able to fix this within the dev freeze time, then it would not > have moved. I believe that the solution you proposed makes sense from technical perspective, but I would still like to have it consulted and aligned with people assigned to RHSTOR-1879, including QE, since during bug triage meeting (when this bug was acked) we agreed that these tasks are closely related and work on it will be coordinated. > > Please consult next steps with QE owner of RHSTOR-1879, until that happens, > > I'm moving it back. One sided override like that is simply not acceptable. > > Please not do it again. > > This is a dev preview feature, which means regression only. > Moreover, this is not a blocker and thus doesn't qualify after we enter dev > freeze. Dev freeze feature level doesn't afaik imply regression testing only. If that has been changed, could you provide a reference to program approved definition? > If you want to see this in 4.9, please mark it a blocker with proper > justification saying why we should not release 4.9 without this fix. I'm not against pushing it out. Actually I would have not provided qa ack if I haven't been told it is related to a new feature. But based on what we agreed on before, the expected course of action here would be: - consider impact of dropping this BZ on RHSTOR-1879 - sync with dev and qe owners of RHSTOR-1879, and note in this bug that it has happened Maybe there is some existing agreement I'm not aware about, but if that is the case, let's reference it here. Looking into known state of this BZ and RHSTOR-1879, I would assume that neither should be part of the 4.9 release.
(In reply to Martin Bukatovic from comment #26) > (In reply to Mudit Agarwal from comment #21) > > We are not going to receive the complete fix via upstream, only rook fix is > > in upstream. > > If we were able to fix this within the dev freeze time, then it would not > > have moved. > > I believe that the solution you proposed makes sense from technical > perspective, > but I would still like to have it consulted and aligned with people assigned > to RHSTOR-1879, including QE, since during bug triage meeting (when this bug > was acked) we agreed that these tasks are closely related and work on it will > be coordinated. I am not providing any solution, I am just saying that the work is incomplete and we don't have time to finish that in the current release. Hence we want to move this out, given that it is not a blocker for the release. Regarding the acks during the triage meeting, when we acked it we were not in a blocker only phase but we are now. > > > Please consult next steps with QE owner of RHSTOR-1879, until that happens, > > > I'm moving it back. One sided override like that is simply not acceptable. > > > Please not do it again. > > > > This is a dev preview feature, which means regression only. > > Moreover, this is not a blocker and thus doesn't qualify after we enter dev > > freeze. > > Dev freeze feature level doesn't afaik imply regression testing only. If > that has > been changed, could you provide a reference to program approved definition? Yeah, sorry my bad, it is not regression only but functionality that MAY NOT be fully tested. > > If you want to see this in 4.9, please mark it a blocker with proper > > justification saying why we should not release 4.9 without this fix. > > I'm not against pushing it out. Actually I would have not provided qa ack if > I haven't been told it is related to a new feature. But based on what we > agreed > on before, the expected course of action here would be: > > - consider impact of dropping this BZ on RHSTOR-1879 > - sync with dev and qe owners of RHSTOR-1879, and note in this bug that it > has happened Impact is mentioned in the above comments, user will need to perform some manual steps which would be well documented via the doc bz.
After having an offline discussion with Eran and Elad, moving this out of 4.9 Have added it as a known issue, will try to fix it in 4.9.z
Please test with any of the latest 4.10 builds.
Version: OCP: 4.10.0-0.nightly-2022-03-16-000645 ODF: 4.10.0-194 CEPH: 16.2.7-76.el8cp (f4d6ada772570ae8b05c62ad79e222fbd3f04188) pacific (stable) prometheus-user got created in openshift-storage and listed as shown in the sample output. Observed the obc related metrics are exported as shown in the attached screenshot [1] and [2] in the comment54, comment 55. Based on the observation moving bug to verified state. Sample output: $ oc get cephobjectstoreuser -n openshift-storage NAME AGE noobaa-ceph-objectstore-user 23h ocs-storagecluster-cephobjectstoreuser 23h prometheus-user 23h
The doc text looks good to me
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 (Important: Red Hat OpenShift Data Foundation 4.10.0 enhancement, security & bug fix 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/RHSA-2022:1372
Doc text was added, thanks Bipin.