starlingx
/
distcloud
Code Issues Proposed changes
distcloud/distributedcloud/dcmanager/api
History
Zhang Rong(Jon) 26bb7011e4 Fix issues with PGA sync_status 
This commit addresses the issue where the primary site's PGA status
remains 'in-sync' even after the secondary site becomes unreachable.
With this fix, the PGA status will be updated to 'unknown' upon the
secondary site's failure. Additionally, the status will transition to
'in-sync' once the secondary site is operational again.
If there are any changes in the association while the secondary site is
down, the PGA status will be set to failed. The sync status will
transition to "out-of-sync" upon secondary site recovery.

In this commit, the audit thread in the primary site will also update
PGA sync_status. If the primary site is down and the SPG is migrated to
secondary site, upon primary site recovery, its audit thread will update
the PGA sync_status on both sites accordingly.

Finally, the commit prevents the peergroup to from being updated in the
secondary site.

Test Case:
1. PASS - Shutdown of site2 (secondary site) results in the
        synchronization status of the peer group association
        transitioning from 'in-sync' to 'unknown'.
2. PASS - Restoration of site2 (secondary site) leads to the
        synchronization status of the peer group association on
        the primary site changing to 'in-sync', and the peer
        group association status on site2 also reflects 'in-sync'.
3. PASS - While secondary is is offline, execute some operations which
        result in PGA sync_status being set to "failed". Recover
        secondary site and verify that the PGA sync_status is set to
        out-of-sync on both sites.
4. PASS - Verify that updating peer group on secondary site is
        disallowed.
5. PASS - Shut down the primary site, migrate the SPG to secondary site.
        Restore the primary site while migration is in progress. Verify
        that the PGA sync_status is out-of-sync. Verify that PGA
        sync_status is set to in-sync shortly after the migration is
        complete.

Closes-Bug: 2055030

Change-Id: I67f4200118621205c539b24eb764e3cc5acf12c0
Signed-off-by: Zhang Rong(Jon) <rong.zhang@windriver.com>
 		2024-03-08 00:41:09 +08:00
..
controllers Fix issues with PGA sync_status 2024-03-08 00:41:09 +08:00
policies Update tox pylint/pep8 for dcmanager 2024-01-18 21:51:25 +00:00
README.rst Move content to subdir to support relocated packaging 2019-11-04 13:57:02 -05:00
__init__.py Move content to subdir to support relocated packaging 2019-11-04 13:57:02 -05:00
api_config.py Implement access control for DC API 2022-09-22 18:26:35 -03:00
app.py Update tox pylint/pep8 for dcmanager 2024-01-18 21:51:25 +00:00
policy.py Update tox pylint/pep8 for dcmanager 2024-01-18 21:51:25 +00:00

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