.NooBaa Backingstore In Phase: "Connecting" with "Invalid URL"
Previously, the operator failed to get the system information in the reconciliation loop which prevented the successful completion of the reconciliation. This was due to a bug in the URL parsing that caused the parsing to fail when the address was IPv6.
With this fix, the case of IPv6 address is handled as the URL host. As a result, the operator successfully completes the system reconciliation.
Description of problem (please be detailed as possible and provide log snippets):
The customer is attempting to upgrade to ODF v4.14 from ODF v4.13 and has been informed to hold off on the upgrade, due to the storagecluster being stuck in the "Progressing" phase because NooBaa is stuck in the "Connecting/Configuring" phase and stating that it's due to an "Invalid URL." This is a disconnected and the endpoint in the backingstore is pointed to the internal service and not an external route. ODF Support has troubleshot this issue, but cannot get NooBaa to get out of the configuring/connecting phase.
Version of all relevant components (if applicable):
OCP:
NAME VERSION AVAILABLE PROGRESSING SINCE STATUS
version 4.13.38 True False 3d23h Cluster version is 4.13.38
ODF:
NAME DISPLAY VERSION REPLACES PHASE
cluster-logging.v5.9.2 Red Hat OpenShift Logging 5.9.2 cluster-logging.v5.8.6 Succeeded
elasticsearch-operator.v5.8.7 OpenShift Elasticsearch Operator 5.8.7 elasticsearch-operator.v5.8.6 Succeeded
mcg-operator.v4.13.8-rhodf NooBaa Operator 4.13.8-rhodf mcg-operator.v4.13.7-rhodf Succeeded
metallb-operator.v4.13.0-202405141537 MetalLB Operator 4.13.0-202405141537 metallb-operator.4.12.0-202405091536 Succeeded
ocs-operator.v4.13.8-rhodf OpenShift Container Storage 4.13.8-rhodf ocs-operator.v4.13.7-rhodf Succeeded
odf-csi-addons-operator.v4.13.8-rhodf CSI Addons 4.13.8-rhodf odf-csi-addons-operator.v4.13.7-rhodf Succeeded
odf-operator.v4.13.8-rhodf OpenShift Data Foundation 4.13.8-rhodf odf-operator.v4.13.7-rhodf Succeeded
quay-operator.v3.11.1 Red Hat Quay 3.11.1 quay-operator.v3.11.0 Succeeded
Ceph:
{
"mon": {
"ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 3
},
"mgr": {
"ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 1
},
"osd": {
"ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 40
},
"mds": {
"ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 2
},
"rgw": {
"ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 1
},
"overall": {
"ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 47
}
}
Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)?
This is a blocker. The customer entered a Maintenance Window to upgrade to v4.14 and in addition to the loss of access to Quay, this is a blocker to upgrade to v4.14 from v4.13 as well.
NAMESPACE NAME BUCKET-NAME STORAGE-CLASS BUCKET-CLASS PHASE
quay-enterprise quay-registry-quay-datastore openshift-storage.noobaa.io noobaa-default-bucket-class Bound
quay-ericsson registry-ericsson-quay-datastore openshift-storage.noobaa.io noobaa-default-bucket-class Bound
quay-oracle registry-oracle-quay-datastore openshift-storage.noobaa.io noobaa-default-bucket-class Bound
Is there any workaround available to the best of your knowledge?
No
Danny,
Evidently, there is something wrong with BugZilla and private comments. I will upload the core logs and database dump to the slack channel thread we were talking in.
Regards,
Craig Wayman
TSE Red Hat OpenShift Data Foundations (ODF)
Customer Experience and Engagement, NA
Comment 21Sunil Kumar Acharya
2024-06-18 06:45:26 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 (Important: Red Hat OpenShift Data Foundation 4.16.0 security, enhancement & 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-2024:4591
Description of problem (please be detailed as possible and provide log snippets): The customer is attempting to upgrade to ODF v4.14 from ODF v4.13 and has been informed to hold off on the upgrade, due to the storagecluster being stuck in the "Progressing" phase because NooBaa is stuck in the "Connecting/Configuring" phase and stating that it's due to an "Invalid URL." This is a disconnected and the endpoint in the backingstore is pointed to the internal service and not an external route. ODF Support has troubleshot this issue, but cannot get NooBaa to get out of the configuring/connecting phase. Version of all relevant components (if applicable): OCP: NAME VERSION AVAILABLE PROGRESSING SINCE STATUS version 4.13.38 True False 3d23h Cluster version is 4.13.38 ODF: NAME DISPLAY VERSION REPLACES PHASE cluster-logging.v5.9.2 Red Hat OpenShift Logging 5.9.2 cluster-logging.v5.8.6 Succeeded elasticsearch-operator.v5.8.7 OpenShift Elasticsearch Operator 5.8.7 elasticsearch-operator.v5.8.6 Succeeded mcg-operator.v4.13.8-rhodf NooBaa Operator 4.13.8-rhodf mcg-operator.v4.13.7-rhodf Succeeded metallb-operator.v4.13.0-202405141537 MetalLB Operator 4.13.0-202405141537 metallb-operator.4.12.0-202405091536 Succeeded ocs-operator.v4.13.8-rhodf OpenShift Container Storage 4.13.8-rhodf ocs-operator.v4.13.7-rhodf Succeeded odf-csi-addons-operator.v4.13.8-rhodf CSI Addons 4.13.8-rhodf odf-csi-addons-operator.v4.13.7-rhodf Succeeded odf-operator.v4.13.8-rhodf OpenShift Data Foundation 4.13.8-rhodf odf-operator.v4.13.7-rhodf Succeeded quay-operator.v3.11.1 Red Hat Quay 3.11.1 quay-operator.v3.11.0 Succeeded Ceph: { "mon": { "ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 3 }, "mgr": { "ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 1 }, "osd": { "ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 40 }, "mds": { "ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 2 }, "rgw": { "ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 1 }, "overall": { "ceph version 17.2.6-196.el9cp (cbbf2cfb549196ca18c0c9caff9124d83ed681a4) quincy (stable)": 47 } } Does this issue impact your ability to continue to work with the product (please explain in detail what is the user impact)? This is a blocker. The customer entered a Maintenance Window to upgrade to v4.14 and in addition to the loss of access to Quay, this is a blocker to upgrade to v4.14 from v4.13 as well. NAMESPACE NAME BUCKET-NAME STORAGE-CLASS BUCKET-CLASS PHASE quay-enterprise quay-registry-quay-datastore openshift-storage.noobaa.io noobaa-default-bucket-class Bound quay-ericsson registry-ericsson-quay-datastore openshift-storage.noobaa.io noobaa-default-bucket-class Bound quay-oracle registry-oracle-quay-datastore openshift-storage.noobaa.io noobaa-default-bucket-class Bound Is there any workaround available to the best of your knowledge? No