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 |
|