Activity log for bug #2057981

Date Who What changed Old value New value Message
2024-03-14 23:25:33 Li Zhu bug added bug
2024-03-14 23:51:39 Li Zhu description Brief Description ----------------- If we do the initial sync with a subcloud containing an incorrect bootstrap-address and try to run a migration to site 2 (let's say the user did not notice the incorrect address). The subcloud migration would fail and it would have the 'rehome-failed' deploy-status on site 2. Now this subcloud is stuck because: - The user can't just run another migrate, as it would still fail due to the incorrect bootstrap-address; - While the user can update the bootstrap-address to the correct value on site1, he won't be able to sync it due to the following issue: "Failed to sync subcloud(s) in the Subcloud Peer Group spg1: {"subcloud1-sc1-ptg": "Ignoring update Peer Site Subcloud subcloud1-sc1-ptg (region_name: subcloud1-sc1-ptg) as is not in secondary state."} ". Obs: Site 1 could also never become available again, so this strategy would be invalid even if the sync worked. - The user won't be able to remove and delete the subcloud from the SPG on site 2 due to: "Removing subcloud from a peer group not led by the current site is prohibited." Severity -------- Major Steps to Reproduce ------------------ 1. Create the system peer from Site A to Site B 2. Create System peer from Site B to Site A 3. Create the subcloud peer group in the Site A 4. Add subcloud(s) to the peer group 5. Create peer group association to associate system peer and subcloud peer group - Site A 6. Check current sync status on Sites A and B. Verify they are 'in-sync'. 7. Update subcloud with an incorrect bootstrap-address on Site A and then sync to Site B 8. Run migration for the subcloud peer group from Site B 9. After rehome fails, update subcloud bootstrap-address on Site A and then sync to Site B, which is supposed to fail 10. update subcloud bootstrap-address on Site B, which is supposed to be rejected Expected Behavior ------------------ The user can correct the subcloud bootstrap-address either on secondary site or on the primary site and then sync to the secondary site. Actual Behavior ---------------- The user can't run another migrate, as it would still fail due to the incorrect bootstrap-address, and the bootstrap-address could not be corrected on the secondary site. Reproducibility --------------- 100% System Configuration -------------------- Distributed Cloud Branch/Pull Time/Commit ----------------------- master (2024-03-12) Last Pass --------- New test scenario Timestamp/Logs -------------- Site A dcmanager.log: 2024-03-14 23:15:20.962 3294 ERROR dcmanager.manager.system_peer_manager [req-e6f45fc7-88a9-4acc-a9a8-85eee0c76eb8 f972b4432e5e41cea4e6f26edd51b641 - - default default] Failed to sync subcloud(s) in the Subcloud Peer Group sc1-subcloud-peer-group: {"subcloud1-sc1": "Ignoring update Peer Site Subcloud subcloud1-sc1 (region_name: 55900716862f4369987c12d50029ce38) as is not in secondary state."} Site B: [sysadmin@controller-0 ~(keystone_admin)]$ dcmanager subcloud update --bootstrap-address 10.10.10.12 subcloud1-sc1 The server could not comply with the request since it is either malformed or otherwise incorrect. Subcloud update is only allowed when its peer group priority value is 0. ERROR (app) Unable to update subcloud subcloud1-sc1 Test Activity ------------- Feature Testing Workaround ---------- None Brief Description ----------------- If the subcloud rehome_data containing an incorrect bootstrap-address on site A and try to migrate to site B, the migration would fail and it would have the 'rehome-failed' deploy-status on site B and 'rehome-pending' deploy-status on site A. Then the user won't be able to update the bootstrap-address on Site B. Although he can update the bootstrap-address on site A, but the change would not be synced to site B. Severity -------- Major Steps to Reproduce ------------------ 1. Create the system peer from Site A to Site B 2. Create System peer from Site B to Site A 3. Create the subcloud peer group in the Site A 4. Add subcloud(s) to the peer group 5. Create peer group association to associate system peer and subcloud peer group - Site A 6. Check current sync status on Sites A and B. Verify they are 'in-sync'. 7. Update subcloud with an incorrect bootstrap-address on Site A and then sync to Site B 8. Run migration for the subcloud peer group from Site B 9. After rehome fails, update subcloud bootstrap-address on Site A and then sync to Site B, which is supposed to fail 10. update subcloud bootstrap-address on Site B, which is supposed to be rejected Expected Behavior ------------------ The user can correct the subcloud bootstrap-address either on secondary site or on the primary site and then sync to the secondary site. Actual Behavior ---------------- The user can't run another migrate, as it would still fail due to the incorrect bootstrap-address, and the bootstrap-address could not be corrected on the secondary site. Reproducibility --------------- 100% System Configuration -------------------- Distributed Cloud Branch/Pull Time/Commit ----------------------- master (2024-03-12) Last Pass --------- New test scenario Timestamp/Logs -------------- Site A dcmanager.log: 2024-03-14 23:15:20.962 3294 ERROR dcmanager.manager.system_peer_manager [req-e6f45fc7-88a9-4acc-a9a8-85eee0c76eb8 f972b4432e5e41cea4e6f26edd51b641 - - default default] Failed to sync subcloud(s) in the Subcloud Peer Group sc1-subcloud-peer-group: {"subcloud1-sc1": "Ignoring update Peer Site Subcloud subcloud1-sc1 (region_name: 55900716862f4369987c12d50029ce38) as is not in secondary state."} Site B: [sysadmin@controller-0 ~(keystone_admin)]$ dcmanager subcloud update --bootstrap-address 10.10.10.12 subcloud1-sc1 The server could not comply with the request since it is either malformed or otherwise incorrect. Subcloud update is only allowed when its peer group priority value is 0. ERROR (app) Unable to update subcloud subcloud1-sc1 Test Activity ------------- Feature Testing Workaround ---------- None
2024-03-14 23:59:45 Li Zhu description Brief Description ----------------- If the subcloud rehome_data containing an incorrect bootstrap-address on site A and try to migrate to site B, the migration would fail and it would have the 'rehome-failed' deploy-status on site B and 'rehome-pending' deploy-status on site A. Then the user won't be able to update the bootstrap-address on Site B. Although he can update the bootstrap-address on site A, but the change would not be synced to site B. Severity -------- Major Steps to Reproduce ------------------ 1. Create the system peer from Site A to Site B 2. Create System peer from Site B to Site A 3. Create the subcloud peer group in the Site A 4. Add subcloud(s) to the peer group 5. Create peer group association to associate system peer and subcloud peer group - Site A 6. Check current sync status on Sites A and B. Verify they are 'in-sync'. 7. Update subcloud with an incorrect bootstrap-address on Site A and then sync to Site B 8. Run migration for the subcloud peer group from Site B 9. After rehome fails, update subcloud bootstrap-address on Site A and then sync to Site B, which is supposed to fail 10. update subcloud bootstrap-address on Site B, which is supposed to be rejected Expected Behavior ------------------ The user can correct the subcloud bootstrap-address either on secondary site or on the primary site and then sync to the secondary site. Actual Behavior ---------------- The user can't run another migrate, as it would still fail due to the incorrect bootstrap-address, and the bootstrap-address could not be corrected on the secondary site. Reproducibility --------------- 100% System Configuration -------------------- Distributed Cloud Branch/Pull Time/Commit ----------------------- master (2024-03-12) Last Pass --------- New test scenario Timestamp/Logs -------------- Site A dcmanager.log: 2024-03-14 23:15:20.962 3294 ERROR dcmanager.manager.system_peer_manager [req-e6f45fc7-88a9-4acc-a9a8-85eee0c76eb8 f972b4432e5e41cea4e6f26edd51b641 - - default default] Failed to sync subcloud(s) in the Subcloud Peer Group sc1-subcloud-peer-group: {"subcloud1-sc1": "Ignoring update Peer Site Subcloud subcloud1-sc1 (region_name: 55900716862f4369987c12d50029ce38) as is not in secondary state."} Site B: [sysadmin@controller-0 ~(keystone_admin)]$ dcmanager subcloud update --bootstrap-address 10.10.10.12 subcloud1-sc1 The server could not comply with the request since it is either malformed or otherwise incorrect. Subcloud update is only allowed when its peer group priority value is 0. ERROR (app) Unable to update subcloud subcloud1-sc1 Test Activity ------------- Feature Testing Workaround ---------- None Brief Description ----------------- If the subcloud rehome_data contains an incorrect bootstrap-address on site A and the user migrates the corresponding pee group to site B, the migration would fail. Subsequently, it will have the 'rehome-failed' deploy-status on site B and 'rehome-pending' deploy-status on site A. Then the user won't be able to update the bootstrap-address on Site B. Although they can update the bootstrap-address on site A, but the change will not be synced to site B. Severity -------- Major Steps to Reproduce ------------------ 1. Create the system peer from Site A to Site B 2. Create System peer from Site B to Site A 3. Create the subcloud peer group in the Site A 4. Add subcloud(s) to the peer group 5. Create peer group association to associate system peer and subcloud peer group - Site A 6. Check current sync status on Sites A and B. Verify they are 'in-sync'. 7. Update subcloud with an incorrect bootstrap-address on Site A and then sync to Site B 8. Run migration for the subcloud peer group from Site B 9. After rehome fails, update subcloud bootstrap-address on Site A and then sync to Site B, which is supposed to fail 10. update subcloud bootstrap-address on Site B, which is supposed to be rejected Expected Behavior ------------------ The user can correct the subcloud bootstrap-address either on secondary site or on the primary site and then sync to the secondary site. Actual Behavior ---------------- The user can't run another migrate, as it would still fail due to the incorrect bootstrap-address, and the bootstrap-address could not be corrected on the secondary site. Reproducibility --------------- 100% System Configuration -------------------- Distributed Cloud Branch/Pull Time/Commit ----------------------- master (2024-03-12) Last Pass --------- New test scenario Timestamp/Logs -------------- Site A dcmanager.log: 2024-03-14 23:15:20.962 3294 ERROR dcmanager.manager.system_peer_manager [req-e6f45fc7-88a9-4acc-a9a8-85eee0c76eb8 f972b4432e5e41cea4e6f26edd51b641 - - default default] Failed to sync subcloud(s) in the Subcloud Peer Group sc1-subcloud-peer-group: {"subcloud1-sc1": "Ignoring update Peer Site Subcloud subcloud1-sc1 (region_name: 55900716862f4369987c12d50029ce38) as is not in secondary state."} Site B: [sysadmin@controller-0 ~(keystone_admin)]$ dcmanager subcloud update --bootstrap-address 10.10.10.12 subcloud1-sc1 The server could not comply with the request since it is either malformed or otherwise incorrect. Subcloud update is only allowed when its peer group priority value is 0. ERROR (app) Unable to update subcloud subcloud1-sc1 Test Activity ------------- Feature Testing Workaround ---------- None
2024-03-15 00:24:20 OpenStack Infra starlingx: status New In Progress
2024-03-20 17:14:36 OpenStack Infra starlingx: status In Progress Fix Released
2024-04-10 14:38:58 Ghada Khalil starlingx: importance Undecided Medium
2024-04-10 14:39:17 Ghada Khalil tags stx.10.0 stx.distcloud
2024-04-10 14:40:02 Ghada Khalil starlingx: assignee Li Zhu (lzhu1)