a6a6b84258
This change adds the capability to rename the subcloud after
bootstrap or during subcloud rehome operation.
Added a field in the database to separate the region name
from the subcloud name.
The region name determines the subcloud reference in the
Openstack core, through which it is possible to access
the endpoints of a given subcloud. Since the region name
cannot be changed, this commit adds the ability to maintain
a unique region name based on the UUID format, and allows
subcloud renaming when necessary without any endpoint
impact.
The region is randomly generated to configure the subcloud
when it is created and only applies to future subclouds.
For those systems that have existing subclouds, the region
will be the same as on day 0, that is, region will keep the
same name as the subcloud, but subclouds can be renamed.
This topic involves changes to dcmanager, dcmanager-client
and GUI. To ensure the region name reference needed by the
cert-monitor, a mechanism to determine if the request is
coming from the cert-monitor has been created.
Usage for subcloud rename:
dcmanager subcloud update <subcloud-name> --name <new-name>
Usage for subcloud rehoming:
dcmanager subcloud add --name <subcloud-name> --migrate ...
Note: Upgrade test from StarlingX 8 -> 9 for this commit
is deferred until upgrade functionality in master is
restored. Any issue found during upgrade test will be
addressed in a separate commit
Test Plan:
PASS: Run dcmanager subcloud passing subcommands:
- add/delete/migrate/list/show/show --detail
- errors/manage/unmanage/reinstall/reconfig
- update/deploy
PASS: Run dcmanager subcloud add supplying --name
parameter and validate the operation is not allowed
PASS: Run dcmanager supplying subcommands:
- kube/patch/prestage strategies
PASS: Run dcmanager to apply patch and remove it
PASS: Run dcmanager subcloud-backup:
- create/delete/restore/show/upload
PASS: Run subcloud-group:
- add/delete/list/list-subclouds/show/update
PASS: Run dcmanager subcloud strategy for:
- patch/kubernetes/firmware
PASS: Run dcmanager subcloud update command passing --name
parameter supplying the following values:
- current subcloud name (not changed)
- different existing subcloud name
PASS: Run dcmanager to migrate a subcloud passing --name
parameter supplying a new subcloud name
PASS: Run dcmanager to migrate a subcloud without --name
parameter
PASS: Run dcmanager to migrate a subcloud passing --name
parameter supplying a new subcloud name and
different subcloud name in bootstrap file
PASS: Test dcmanager API response using cURL command line
to validate new region name field
PASS: Run full DC sanity and regression
Story: 2010788
Task: 48217
Signed-off-by: Cristian Mondo <cristian.mondo@windriver.com>
Change-Id: Id04f42504b8e325d9ec3880c240fe4a06e3a20b7
|
||
|---|---|---|
| .. | ||
| 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