Chapter 6. Bug fixes

noobaa-db-pg-cluster now synchronizes successfully without WAL segment errors

The noobaa-db-pg-cluster database cluster now synchronizes properly and avoids synchronization loops. Previously, the cluster would stop synchronizing and log an error indicating that a requested Write-Ahead Logging (WAL) segment had already been removed. To resolve this and increase replication resiliency, the configuration parameters wal_keep_size, wal_level, wal_sender_timeout, wal_receiver_timeout, and failoverDelay have been updated for NooBaa’s PostgreSQL database usage.

(DFBUGS-6943)

Intermittent S3 upload failures (HTTP 500) to NooBaa buckets have been resolved

Uploading files to NooBaa buckets via JFrog Artifactory no longer fails intermittently with HTTP 500 / InternalError. Previously, concurrent PUT uploads to the same bucket and key could cause a database unique constraint conflict when attempting to update version records simultaneously, causing the second upload to fail. This issue has been resolved by implementing internal retry logic within the upload completion flow.

(DFBUGS-6548)

NooBaa database cleaner environment variables are no longer overridden during reconciliation

Environment variables configured for the NooBaa database cleaner (DB_CLEANER) now properly persist and take effect. Previously, the noobaa-operator would overwrite custom environment variables on the core pod during its reconciliation loop, causing user-defined values (such as database cleaner timers) to be ignored. This issue has been resolved by ensuring the operator retains and respects existing custom configurations.

(DFBUGS-5052)

The PodDisruptionBudgetAtLimit alert for the noobaa-db-pg-cluster-primary PDB is now automatically silenced

A misleading warning alert is no longer triggered for single-primary database configurations. Previously, CloudNativePG (the database operator used by NooBaa) created a PodDisruptionBudget (PDB) object to protect the primary database instance from deletion. Because there is only one primary, the PDB correctly allowed zero disruptions, which inadvertently caused OpenShift to fire a misleading PodDisruptionBudgetAtLimit warning alert. This issue has been resolved by updating the NooBaa operator to automatically silence this specific alert using the Alertmanager API.

(DFBUGS-5294)

noobaa-core logs are no longer spammed by SignatureDoesNotMatch errors

S3 operations now succeed without signature validation failures, and the noobaa-core logs are no longer filled with error messages. Previously, a regression introduced during the migration to AWS SDK V3 caused incorrect signature calculations, which resulted in failed S3 operations and log spam. This issue has been resolved by removing applyChecksum from the requests.

(DFBUGS-4461)

Regional-DR is now supported in environments deployed on IBM Power

Regional-DR is now supported in OpenShift Data Foundation environments deployed on IBM Power because ACM 2.15 support has been introduced for this platform in this release. This applies to both new and upgraded deployments on IBM Power.

(DFBUGS-5369)

CIDR range does now persists in csiaddonsnode object when the respective node is down

The Classless Inter-Domain Routing (CIDR) information now correctly persists in the csiaddonsnode object even when a node is down. This ensures the fencing mechanism functions as intended when required to fence impacted nodes, eliminating the need to manually collect CIDR information immediately after the NetworkFenceClass object is created.

(DFBUGS-2948)

Remove DR option is now available for discovered apps on the Virtual machines page

The Remove DR option is now available for discovered applications listed on the Virtual machines page. You no longer need to manually add the missing label to the DRPlacementControl or patch the PROTECTED_VMS recipe parameter as a workaround.

(DFBUGS-2823)

DR Status is now displayed for discovered apps on the Virtual machines page

The DR Status is now correctly displayed for discovered applications listed on the Virtual machines page. Manually adding the missing label to the DRPlacementControl and patching the PROTECTED_VMS recipe parameter is no longer required.

(DFBUGS-2822)

Secondary PVCs are now removed when DR protection is removed for discovered apps

On the secondary cluster, CephFS PVCs linked to a workload discovered using the Discovered Applications feature are now correctly marked as VRG-owned. As a result, when the workload is disabled, these PVCs are automatically cleaned up and no longer become orphaned, eliminating the need to manually delete them.

(DFBUGS-2827)

VolSync data mover pods can now access persistent volumes in environments with custom SCCs

Data replication operations no longer fail due to permission restrictions in clusters that enforce custom Security Context Constraints (SCCs). Previously, VolSync data mover pods lacked the necessary privileges to access underlying persistent volumes under restrictive security policies, causing synchronization to fail. This issue has been resolved by introducing a VolSyncSpec field to the DRPlacementControl (DRPC) specification, which allows users to explicitly define a custom MoverSecurityContext and MoverServiceAccount that are successfully propagated to the underlying components.

(DFBUGS-4728)

Custom s3StoreProfile configuration values are no longer lost after an upgrade

Upgrading the OpenShift Data Foundation operator no longer causes custom configurations to be wiped from the Ramen configuration. Previously, the Multicluster Orchestrator (MCO) operator would reconcile the ramen-hub-operator-config ConfigMap without accounting for existing custom values, leading to the loss of the CACertificates and veleroNamespaceSecretKeyRef fields under s3StoreProfiles. This issue has been resolved by updating the MCO operator to properly respect and preserve these custom values during upgrades.

(DFBUGS-440)

Sync no longer stops after PVC deselection

Sync operations now continue to function correctly when a PersistentVolumeClaim (PVC) is added to or removed from a group by modifying its label. Stale protected PVC entries are now properly cleaned up from the VolumeReplicationGroup (VRG) status, eliminating the need to manually edit the VRG’s status field as a workaround.

(DFBUGS-4012)

OSD disks are now properly zapped and cleaned during reinstallation

Disk zapping and cleanup logic now runs successfully during reinstallation even if the initial disk metadata offsets have been modified or cleared by external automation. Previously, the cleanup process relied on a mechanism that only checked the first location for BlueStore metadata; if it was missing, the process skipped zapping the rest of the disk, leaving remaining metadata intact. This issue has been resolved by migrating the disk cleanup logic directly into Rook and removing dependencies on external zapping commands.

(DFBUGS-5549)

Ceph monitors can now successfully form a quorum during a network partition between data centers

A network split between data sites no longer causes Ceph commands and I/O operations to hang indefinitely. Previously, when the two main data centers lost connectivity with each other but maintained communication with the Arbiter node, a flaw in the monitor election logic triggered an endless loop of leader elections. This rendered the Ceph cluster unavailable and required administrators to manually shut down monitors in one data center and reset connection scores as a workaround. This issue has been resolved by fixing the election logic to handle asymmetric network disruptions correctly.

(DFBUGS-425)

UI no longer shows "Unauthorized" error and temporary blank loading screen during ODF operator installation

During the OpenShift Data Foundation operator installation, the page now correctly handles instances where the InstallPlan transiently goes missing. The UI no longer displays an unknown status, "Unauthorized" error, or a temporary blank screen with missing titles and messages.

(DFBUGS-3574)

OpenShift Data Foundation console no longer incorrectly displays internal clusters as external

The OpenShift Data Foundation web console now accurately identifies and displays the cluster deployment mode. Previously, the console determined whether a cluster was internal or external based solely on the presence of the externalStorage.enable field rather than its actual boolean value, occasionally causing internal clusters to be misidentified as external. This issue has been resolved by verifying the exact boolean state of the field.

(DFBUGS-6242)

The kube-apiserver no longer logs 404 error messages originating from OpenShift Data Foundation

The kube-apiserver no longer generates frequent HTTP 404 (Not Found) error logs related to OpenShift Data Foundation internal requests or endpoints. This issue has been resolved by correcting the underlying missing or misconfigured resource requests between OpenShift Data Foundation components and the Kubernetes API server.

(DFBUGS-784)

odf-blackbox-exporter deployment no longer fails when upgrading

The odf-blackbox-exporter deployment now upgrades successfully without failure. Previously, when upgrading to certain OpenShift Data Foundation versions, the deployment would fail, requiring administrators to manually delete the deployment as a workaround. This issue has been resolved.

(DFBUGS-6789)

Encrypted OSDs are no longer unnecessarily redeployed during a 4.19.z upgrade

Upgrading legacy clusters (originally deployed on version 4.10 or earlier) to version 4.19 no longer triggers unnecessary OSD migrations and data movement. Previously, a checking mechanism failed to account for the legacy spec.encryption.enable setting, causing already-encrypted OSDs to be treated as unencrypted and migrated sequentially. This issue has been resolved by properly respecting the legacy encryption setting.

(DFBUGS-6696)

External clusters no longer upgrade OpenShift Data Foundation automatically without manual approval

When upgrading OpenShift Container Platform, external OpenShift Data Foundation clusters now correctly respect manual approval settings for installation plans. Previously, the ocs-operator did not set the disableInstallPlanAutoApproval key in the ocs-client-operator-config ConfigMap for external deployments, which caused the client-operator to automatically approve installation plans unexpectedly. This issue has been resolved by ensuring the key is set across all cluster types.

(DFBUGS-6043)