cd355ca120
This commit adds the rehome-pending deploy status, which should be used
when unmanaging a subcloud before the rehoming/migration operation.
This new status will then be used by cert-mon to determine when it
should stop auditing an unmanaged subcloud, to avoid certificate
issues during the rehoming operation.
It's only possible to switch to this state when the subcloud is being
unmanaged and its deploy status is 'complete'. It's possible to manage
it back in case the rehoming operation is not going to be executed
anymore; in this case the deploy-status will be reverted back to
'complete'.
Example usage:
dcmanager subcloud unmanage --migrate subcloud1
CURL:
curl -X PATCH -H "X-Auth-Token: ${TOKEN//[$'\t\r\n']}" \
"http://$MGMT_IP:8119/v1.0/subclouds/{subcloud1}" \
-F migrate="true" \
-F management-state="unmanaged"
Test Plan:
1. PASS - Unmanage a subcloud without --migrate and verify that it
still works and that cert-mon continues to audit it;
2. PASS - Manage a subcloud, verify that the operation still works as
expected;
3. PASS - Try to unmanage with --migrate when the subcloud's deploy
status is different than 'complete' and verify that it
doesn't allow it;
4. PASS - Unmanage a subcloud using the --migrate option and verify
that its deploy status changes to 'rehome-pending', all the
sync statuses change to 'unknown', and that cert-mon stops
auditing the subcloud;
5. PASS - By directly calling the SubcloudManager.update_subcloud()
method (internally, skipping API validation), verify that:
- it's possible to update the deploy_status to 'secondary'
while also updating its management_state to 'unmanaged';
- it's possible to update the deploy_status to
'rehome-pending' while also updating its management_state
to 'unmanaged';
- it's NOT possible to update the deploy_status if the
subcloud is not already unmanaged or its management_state
is not being updated to 'unmanaged';
- it's possible to update the deploy_status to 'secondary'
for a subcloud that's already unmanaged;
- it's possible to update the deploy_status to 'secondary'
for a subcloud that's already unmanaged and currently in
the 'rehome-pending' state.
- Try to manage a 'rehome-pending' subcloud while also
changing its deploy status to something different than
'complete', verify that it fails;
6. PASS - Manage a 'rehome-pending' subcloud and verify that it
succeeds while also reverting its deploy_status to
'complete';
7. PASS - Run subcloud update to populate the rehome_data with the
bootstrap values and address, verify that it still works.
Story: 2010852
Task: 49059
Signed-off-by: Gustavo Herzmann <gustavo.herzmann@windriver.com>
Change-Id: I8bf76904e335e382407c2268a9c1879471ef2fc9
|
||
|---|---|---|
| .. | ||
| 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