ade017ce68
For subcloud phase deploy story (2010756), the previous deploy_status for the subcloud configuration step were replaced. If a subcloud in a failed deploy state remained after an upgrade, it was not possible to re-run the deploy config step. This commit changes the deploy status of subclouds from 'deploy-prep-failed' to 'pre-config-failed' and from 'deploy-failed' to 'config-failed', allowing the user to run 'dcmanager subcloud deploy config'. Test plan: - PASS: Upgrade a system controller from STX-8 to master and verify the data-migration step runs successfully on controller-1 and the subclouds deploy_status were updated from 'deploy-prep-failed' to 'pre-config-failed' and 'deploy-failed' to 'config-failed'. Verify that other subclouds with different deploy_status remain untouched. Notes about the tests: - There was a mismatch on dcmanager db migrate scripts between the developers ISOs used for the test. The STX-8 had a migrate_version of 15, but the last script on master was 16, and said script was already applied on STX-8. For testing, the migrate_version on dcmanager db was updated with: psql -x -d dcmanager -c "update migrate_version set version=16" - The hieradata file (/opt/platform/puppet/23.09/hieradata/) from hosts was updated to use the hostname instead of management ip. To be able to unlock controller-1, it was necessary to rename said file from "controller-1.yaml" to "<mgmt_ip>.yaml". - Post unlock, controller-1 transitioned to unlock-disabled-failed and software.log showed an rsync error because of "Unknown module: 'software'". As the migrate script was already executed successfully, the test ended here. The error was: command: rsync -acv --delete rsync://controller/software/ /opt/software/ sync error: error starting client-server protocol (code 5) at main.c(1817) [Receiver=3.2.3] Story: 2010756 Task: 49402 Change-Id: Id9b43a6d087f1fba4132f24340ad368f01daac5d Signed-off-by: Victor Romano <victor.gluzromano@windriver.com> |
||
---|---|---|
api-ref/source | ||
config-gate | ||
controllerconfig | ||
devstack | ||
doc | ||
releasenotes | ||
storageconfig | ||
sysinv | ||
tmp/patch-scripts/EXAMPLE_SYSINV/scripts | ||
tools/docker/images | ||
tsconfig | ||
workerconfig | ||
.gitignore | ||
.gitreview | ||
.yamllint | ||
.zuul.yaml | ||
CONTRIBUTORS.wrs | ||
LICENSE | ||
README.rst | ||
bindep.txt | ||
centos_build_layer.cfg | ||
centos_dev_wheels.inc | ||
centos_iso_image.inc | ||
centos_pkg_dirs | ||
centos_pkg_dirs_containers | ||
centos_stable_wheels.inc | ||
debian_build_layer.cfg | ||
debian_iso_image.inc | ||
debian_pkg_dirs | ||
debian_stable_wheels.inc | ||
test-requirements.txt | ||
tox.ini |
README.rst
config
The starlingx/config repository handles the StarlingX configuration management services.
Its key component is the System Inventory Service (Sysinv), which provides the system command-line interface (CLI)1.
This repository is not intended to be developed standalone, but rather as part of the StarlingX Source System, which is defined by the StarlingX manifest2.