第 6 章 程序错误修复

阻塞列表不再会导致 pod 处于错误状态

在以前的版本中，由于网络问题或大量过载或具有大量尾部延迟激增的集群阻止列表。因此，Pods 会停留在 CreateContainerError，并带有信息 Error: relabel failed /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount: lsetxattr /var/lib/kubelet/pods/cb27938e-f66f-401d-85f0-9eb5cf565ace/volumes/kubernetes.io~csi/pvc-86e7da91-29f9-4418-80a7-4ae7610bb613/mount/#ib_16384_0.dblwr: read-only file system。

在这个版本中，阻止列表不再会导致 pod 处于错误状态。

(BZ#2094320)

Ceph 现在识别由 Globalnet 分配的全局 IP

在以前的版本中，Ceph 无法识别 Globalnet 分配的全局 IP，因此无法使用 Globalnet 在具有重叠服务 CIDR 的集群间配置灾难恢复解决方案。这个问题已被解决，现在灾难恢复解决方案在服务 CIDR 重叠时可以正常工作。

(BZ#2104971)

当工作负载通过或重新定位到对等集群时，PeerReady 状态不再被设置为 true，直到从中清理或重新定位的集群为止

在以前的版本中，在启动灾难恢复(DR)操作后，当工作负载故障转移或重新定位到对等集群时，PeerReady 条件会在持续时间内最初设置为 true。把它设置为 false 后，直到从其中清理或重新定位到集群被清理或重新定位到集群以进行将来的操作。查看 DRPlacementControl 状态条件的用户可能已将这个中间 PeerReady 状态识别为对等状态，以便采取行动并执行。这会导致操作待处理或失败，并可能需要用户干预才能从中恢复。

在这个版本中，在清理失败或重新定位工作负载前，PeerReady 状态不再被设置为 true，因此用户不再有混淆。

(BZ#2138855)

当 ACM hub 在灾难后恢复时，应用程序不再处于 Cleaningup 状态

在以前的版本中，当 ACM hub 在灾难过程中丢失，并使用备份恢复时，VRG ManifestWork 和 DRPC 状态不会被恢复。这会导致应用程序处于 Cleaningup 状态。

在这个版本中，Ramen 可确保 VRG ManifestWork 是 ACM 备份的一部分，并在 hub 恢复后重新创建 DRPC 状态，应用程序可以成功迁移到故障转移集群。

(BZ#2162469)

基于 STS 的应用程序现在可以按预期重新定位

在以前的版本中，因为底层程序错误，重新定位基于 STS 的应用程序会失败。这个程序错误已被解决，重新定位基于 STS 的应用程序现在可以正常工作。

(BZ#2224325)

hub 恢复后 ramen 协调

在以前的版本中，当使用主动/被动 Hub Metro-DR 设置时，您可能会遇到罕见的场景，Ramen 协调器会在超过其允许速率限制参数后停止运行。因为协调特定于每个工作负载，因此只有该工作负载会受到影响。在这种情况下，与那个工作负载相关的所有灾难恢复编配活动停止直到 Ramen pod 重启为止。

这个问题已被解决，在 hub 恢复后 Ramen 协调如预期。

(BZ#2175201)

在 hub 恢复过程中不会删除受管资源

在以前的版本中，在 hub 恢复过程中，OpenShift Data Foundation 遇到 Red Hat Advanced Cluster Management 版本 2.7.4 （或更高）的已知问题，其中某些与基于订阅的工作负载关联的资源可能会被意外删除。

这个问题已被解决，在 hub 恢复过程中不会删除受管资源。

(BZ#2211643)