6.2. Multicloud Object Gateway

OpenShift Data Foundation does not support automatic data integrity checks through AWS SDKs

AWS Software Development Kits (SDKs) support data integrity checks by default. Previously, these checks were opt-in. OpenShift Data Foundation does not support the default behavior of automatic data integrity checks.

(DFBUGS-1537)

NooBaa Core cannot assume role with web identity due to a missing entry in the role’s trust policy

For OpenShift Data Foundation deployments on AWS using AWS Security Token Service (STS), you need to add another entry in the trust policy for noobaa-core account. This is because with the release of OpenShift Data Foundation 4.17, the service account has changed from noobaa to noobaa-core.

For instructions to add an entry in the trust policy for noobaa-core account, see the final bullet in the prerequisites section of Updating Red Hat OpenShift Data Foundation 4.16 to 4.17.

(BZ#2322124)

Multicloud Object Gateway instance fails to finish initialization

Due to a race in timing between the pod code run and OpenShift loading the Certificate Authority (CA) bundle into the pod, the pod is unable to communicate with the cloud storage service. As a result, the default backing store cannot be created.

Workaround: Restart the Multicloud Object Gateway (MCG) operator pod:

$ oc delete pod noobaa-operator-<ID>

With the workaround the backing store is reconciled and works.

(BZ#2271580)

Upgrade to OpenShift Data Foundation 4.17 results in noobaa-db pod CrashLoopBackOff state

Upgrading to OpenShift Data Foundation 4.17 from OpenShift Data Foundation 4.15 fails when the PostgreSQL upgrade fails in Multicloud Object Gateway which always start with PostgresSQL version 15. If there is a PostgreSQL upgrade failure, the NooBaa-db-pg-0 pod fails to start.

Workaround: Refer to the knowledgebase article Recover NooBaa’s PostgreSQL upgrade failure in OpenShift Data Foundation 4.17.

(BZ#2298152)