5f132a43ab
Fix the reported issue:
The PGA fails to transition from 'in-sync' to 'out-of-sync' after
updating subclouds.
This commit includes the following changes:
1. Updates the SPG sync_status to 'out-of-sync' after performing any of
the following operations and provides an informative message to
the operator:
a) Adding a subcloud to the SPG
b) Removing a subcloud from the SPG
c) Updating a subcloud in the SPG
2. Ensures that updates on SPG attributes, such as name,
max_subcloud_rehoming, and group_state, are automatically
propagated to the peer site.
Test plan:
Pre-Steps: 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'.
PASS: Verify 'out-of-sync' on both sites after running any of
the following operations on site A, the primary and leader site:
1. Adding subcloud to the SPG.
2. Removing subcloud from the SPG.
3. Updating any field of a subcloud in the SPG, such as bootstrap
address, bootstrap values, install values, etc.
PASS: Repeat the above operations while site B is down and verify that
PGA sync_status is set to "failed".
PASS: Verify that SPG attribute updates are accepted if peer site is up
and the updates are successfully synced to the peer site.
PASS: Verify that SPG attribute updates are rejected if the peer site
is down.
PASS: Verify that if the subcloud does not belong to any peer group, or
if it is part of a peer group but the peer group is not associated
with any peer yet, updating the subcloud would not result in an
"informative" message and no attempt to update the PGA sync_status
should occur.
Closes-Bug: 2054123
Closes-Bug: 2054124
Change-Id: I9f0e44e34c7db5d60d211b70e839606d0361cf83
Signed-off-by: lzhu1 <li.zhu@windriver.com>
|
||
|---|---|---|
| .. | ||
| controllers | ||
| policies | ||
| README.rst | ||
| __init__.py | ||
| api_config.py | ||
| app.py | ||
| policy.py | ||
README.rst
api
DC Manager API is Web Server Gateway Interface (WSGI) application to receive and process API calls, including keystonemiddleware to do the authentication, parameter check and validation, convert API calls to job rpc message, and then send the job to DC Manager Manager through the queue. If the job will be processed by DC Manager Manager in synchronous way, the DC Manager API will wait for the response from the DC Manager Manager. Otherwise, the DC Manager API will send response to the API caller first, and then send the job to DC Manager Manager in asynchronous way.
Multiple DC Manager API could run in parallel, and also can work in multi-worker mode.
Multiple DC Manager API will be designed and run in stateless mode, persistent data will be accessed (read and write) from the DC Manager Database through the DAL module.
Setup and encapsulate the API WSGI app
- app.py:
-
Setup and encapsulate the API WSGI app, including integrate the keystonemiddleware app
- api_config.py:
-
API configuration loading and init
- enforcer.py
-
Enforces policies on the version2 APIs