Back to bug 2138855
| Who | When | What | Removed | Added |
|---|---|---|---|---|
| Sunil Kumar Acharya | 2022-11-02 03:27:35 UTC | Flags | needinfo?(srangana) | |
| CC | srangana | |||
| Shyamsundar | 2022-11-08 11:53:13 UTC | Flags | needinfo?(srangana) | needinfo?(gshanmug) |
| CC | gshanmug | |||
| Elad | 2022-11-13 12:10:06 UTC | CC | ebenahar | |
| RHEL Program Management | 2022-11-13 12:10:13 UTC | Target Release | --- | ODF 4.12.0 |
| Mudit Agarwal | 2022-11-14 13:21:37 UTC | Status | NEW | ASSIGNED |
| Sunil Kumar Acharya | 2022-12-08 12:52:38 UTC | Flags | needinfo?(srangana) | |
| Shyamsundar | 2022-12-09 13:08:53 UTC | Flags | needinfo?(srangana) | |
| Doc Type | If docs needed, set a value | Known Issue | ||
| Doc Text | Cause: Post a DR action is initiated, the PeerReady condition is initially set to true for the duration when the workload is failedover or relocated to the peer cluster, post which it is set to false till the cluster from where it was failedover or relocated from is cleaned up for future actions. Consequence: A user looking at DRPlacementControl status conditions for future actions may recognize this intermediate PeerReady state as a peer being ready for an action and perform the same. This will result in the operation pending or failing and may require user intervention to recover from. Workaround (if any): Examine both Available and PeerReady states before performing any actions. Both should be true for a healthy DR state for the workload. Result: Actions performed when both states are true will result in the requested operation progressing |
|||
| Red Hat Bugzilla | 2022-12-31 22:37:06 UTC | CC | ebenahar | |
| Red Hat Bugzilla | 2023-01-01 05:47:45 UTC | Assignee | srangana | nobody |
| CC | srangana | |||
| Red Hat Bugzilla | 2023-01-01 08:31:50 UTC | QA Contact | kramdoss | |
| Mudit Agarwal | 2023-01-03 07:27:11 UTC | Assignee | nobody | srangana |
| Flags | needinfo?(gshanmug) | |||
| RHEL Program Management | 2023-01-03 07:27:20 UTC | Target Release | ODF 4.12.0 --- | --- ODF 4.13.0 |
| Mudit Agarwal | 2023-01-03 07:38:16 UTC | Blocks | 2107226 | |
| Alasdair Kergon | 2023-01-04 04:40:03 UTC | QA Contact | kramdoss | |
| Alasdair Kergon | 2023-01-04 05:46:39 UTC | CC | srangana | |
| Alasdair Kergon | 2023-01-04 06:41:59 UTC | CC | ebenahar | |
| Erin Donnelly | 2023-01-12 23:09:32 UTC | CC | edonnell | |
| Doc Text | Cause: Post a DR action is initiated, the PeerReady condition is initially set to true for the duration when the workload is failedover or relocated to the peer cluster, post which it is set to false till the cluster from where it was failedover or relocated from is cleaned up for future actions. Consequence: A user looking at DRPlacementControl status conditions for future actions may recognize this intermediate PeerReady state as a peer being ready for an action and perform the same. This will result in the operation pending or failing and may require user intervention to recover from. Workaround (if any): Examine both Available and PeerReady states before performing any actions. Both should be true for a healthy DR state for the workload. Result: Actions performed when both states are true will result in the requested operation progressing | .`PeerReady` state is set to `true` when a workload is failed over or relocated to the peer cluster until the cluster from where it was failed over or relocated from is cleaned up After a disaster recovery (DR) action is initiated, the `PeerReady` condition is initially set to `true` for the duration when the workload is failed over or relocated to the peer cluster. After this it is set to `false` until the cluster from where it was failed over or relocated from is cleaned up for future actions. A user looking at `DRPlacementControl` status conditions for future actions may recognize this intermediate `PeerReady` state as a peer being ready for an action and perform the same. This will result in the operation pending or failing and may require user intervention to recover from. To workaround this issue, examine both `Available` and `PeerReady` states before performing any actions. Both should be `true` for a healthy DR state for the workload. Actions performed when both states are true will result in the requested operation progressing |
||
| Red Hat Bugzilla | 2023-01-31 23:38:13 UTC | CC | madam | |
| Aman Agrawal | 2023-02-01 09:08:14 UTC | Summary | [RDR] When relocate is performed initially, Peer Ready isn't marked as False | [RDR] When relocate is performed, Peer Ready isn't marked as False |
| Shyamsundar | 2023-02-13 22:22:14 UTC | Link ID | Github RamenDR/ramen/issues/715 | |
| Karolin Seeger | 2023-03-06 13:44:10 UTC | CC | kseeger | |
| Sunil Kumar Acharya | 2023-04-10 12:32:08 UTC | Flags | needinfo?(srangana) | |
| Sunil Kumar Acharya | 2023-04-11 12:42:54 UTC | Flags | needinfo?(srangana) | |
| CC | sheggodu | |||
| krishnaram Karthick | 2023-04-25 06:13:44 UTC | QA Contact | kramdoss | sagrawal |
| Shyamsundar | 2023-05-08 12:57:55 UTC | Status | ASSIGNED | MODIFIED |
| Assignee | srangana | bmekhiss | ||
| Mudit Agarwal | 2023-05-09 12:28:14 UTC | Doc Text | .`PeerReady` state is set to `true` when a workload is failed over or relocated to the peer cluster until the cluster from where it was failed over or relocated from is cleaned up After a disaster recovery (DR) action is initiated, the `PeerReady` condition is initially set to `true` for the duration when the workload is failed over or relocated to the peer cluster. After this it is set to `false` until the cluster from where it was failed over or relocated from is cleaned up for future actions. A user looking at `DRPlacementControl` status conditions for future actions may recognize this intermediate `PeerReady` state as a peer being ready for an action and perform the same. This will result in the operation pending or failing and may require user intervention to recover from. To workaround this issue, examine both `Available` and `PeerReady` states before performing any actions. Both should be `true` for a healthy DR state for the workload. Actions performed when both states are true will result in the requested operation progressing | |
| Doc Type | Known Issue | Bug Fix | ||
| Jenkins Automation for Ceph (Ken Dreyer) | 2023-05-09 18:24:06 UTC | Fixed In Version | 4.13.0-184 | |
| Jenkins Automation for Ceph (Ken Dreyer) | 2023-05-09 20:24:41 UTC | Status | MODIFIED | ON_QA |
| Sidhant Agrawal | 2023-05-17 12:14:28 UTC | Status | ON_QA | ASSIGNED |
| Benamar Mekhissi | 2023-05-19 13:50:44 UTC | Flags | needinfo?(sagrawal) | |
| CC | sagrawal | |||
| Sidhant Agrawal | 2023-05-22 15:12:08 UTC | Flags | needinfo?(sagrawal) | |
| RHEL Program Management | 2023-05-30 11:42:15 UTC | Target Release | ODF 4.13.0 | --- |
| RHEL Program Management | 2023-06-17 07:28:05 UTC | Target Release | --- | ODF 4.14.0 |
| Red Hat Bugzilla | 2023-08-03 08:28:33 UTC | CC | ocs-bugs | |
| Elad | 2023-08-09 17:00:43 UTC | CC | odf-bz-bot | |
| Karolin Seeger | 2023-08-11 08:02:41 UTC | Link ID | Github RamenDR/ramen/pull/1020 | |
| OpenShift BugZilla Robot | 2023-08-11 13:45:33 UTC | Status | ASSIGNED | POST |
| OpenShift BugZilla Robot | 2023-08-11 13:45:35 UTC | Link ID | Github red-hat-storage/ramen/pull/121 | |
| OpenShift BugZilla Robot | 2023-08-11 13:56:21 UTC | Status | POST | MODIFIED |
| Jenkins Automation for Ceph (Ken Dreyer) | 2023-08-14 03:22:41 UTC | Fixed In Version | 4.13.0-184 | 4.14.0-108 |
| Status | MODIFIED | ON_QA |
Back to bug 2138855