Fedora Account System
Red Hat Associate
Red Hat Customer
Description of problem (please be detailed as possible and provide log snippests): After completing the install of OCS 4.5, the routes on the openshift-storage namespace look like this: NAME HOST/PORT PATH SERVICES PORT TERMINATION WILDCARD noobaa-mgmt noobaa-mgmt-openshift-storage.apps.cnv.massopen.cloud noobaa-mgmt mgmt-https reencrypt None s3 s3-openshift-storage.apps.cnv.massopen.cloud s3 s3-https reencrypt None There is a route for the Noobaa S3 API, but there is no route for Ceph RGW. This looks like we are intending to signal a strong preference for using Noobaa, but I don't think that's the case. The installer should also create a route for ceph-rgw. Version of all relevant components (if applicable): OCP 4.5.13 baremetal OCS 4.5.0 Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? This caused problems because the apparent preference for Noobaa led me to start working with that API, only to find out that Noobaa has limited S3 api support (e.g., it seems to be missing support for bucket acls and policies, object tagging, etc). Is there any workaround available to the best of your knowledge? I manually added an appropriate route to the openshift-storage namespace. Rate from 1 - 5 the complexity of the scenario you performed that caused this bug (1 - very simple, 5 - very complex)? 2 Can this issue reproducible? Yes Can this issue reproduce from the UI? Yes Steps to Reproduce: 1. install cs 2. run oc -n openshift-storage get routes Actual results: There is no route for ceph-rgw Expected results: There should be a route for ceph-rgw
Assigning to ocs-op to create the route once the CephObjectStore has been created.
Since RGW is an important component for BM deployments, marking it as a blocker for now, so that the fix can be included in 4.6. We can discuss if required.
Based on an offline discussion, this BZ was moved to 4.7 As agreed, I will be creating a doc clone for this.
Since the route is so closely tied to the RGW service, I would see that Rook should create the route as part of the object store reconcile, similar to how noobaa creates its route. This would involve the following... 1. A new property would be added to the CephObjectStore CRD in Rook that indicates whether to create the route. The object store reconcile would create the route if it's set. (It might be something more complex than a bool, but at a glance that may be sufficient.) createRoute: true 2. The OCS operator would set this to true in the object store CR. 3. In the Rook repo, the object OpenShift example (object-openshift.yaml) would set this value to true. The k8s examples (object.yaml and object-test.yaml) would not set this value. Since work is needed in both the OCS operator and Rook, we may want to clone this BZ.
We are now moving with a new direction on creating the route. On the Rook side, we'll be creating the route as an object OpenShift example in (object-openshift.yaml) no changes in the codes. See discussion https://github.com/rook/rook/pull/7079#issuecomment-768653963
Example route is merged downstream with https://github.com/openshift/rook/pull/157 But we really don't need to verify this downstream since the route will be created by the OCS operator (separate BZ). This BZ is just for informational purposes.
Not a blocker any more.
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 (Moderate: Red Hat OpenShift Container Storage 4.7.0 security, 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/RHSA-2021:2041