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