Cristian Mondo be476cc56b Adapt the prestage to support subcloud rehoming
When a subcloud is rehomed from one DC to a new DC, It has to
be able to reach the release level of the new DC.

The prestage for software deploy prepares the release level
that the subcloud should have deployed based on the release
level of the new DC.

This change affects the following scenarios:
- Subcloud with the same patch level as the system
  controller.
- Subcloud with a patch level lower than that of the
  system controller.
- System controller with a pre-patched load and
  subcloud with the same patch level applied.
- Subcloud with release N-1 and USM support.

Test Plan:
Setup 1: - Bring up a DC#1 with 24.09 and at least 1 subcloud.
	 - Bring up a DC#2 with 24.09.

PASS: - Rehome subcloud from DC#1 to DC#2.
      - Verify that the rehome is completed.
      - On DC#2 prestage the subcloud for software deploy.
      - Verify that the prestage is skipped because subcloud
        has the same release as the system controller.

PASS: - Upload and deploy patch 24.09.1 on DC#2.
      - Prestage the subcloud for software deploy.
      - Verify that the 24.09.1 patch is prestaged on the subcloud.

PASS: - Rehome subcloud from DC#2 to DC#1.
      - Verify that the rehome is completed.
      - On DC#1 prestage the subcloud for software deploy.
      - Verify that the prestage is skipped because the subcloud
        has a higher patch level than the system controller.

Setup 2: - Bring up a DC#1 with 22.12p5 (without USM feature)
           and at least 1 subcloud with the same release.
         - Bring up a DC#2 with 24.09.

PASS: - Rehome subcloud from DC#1 to DC#2.
      - Verify that the rehome is completed.
      - On DC#2 prestage the subcloud for software deploy.
      - Verify that the prestage is rejected because the USM
        service is not available on the subcloud.

PASS: - Upload and apply USM patch on the subcloud.
      - Verify that the USM service is now available.
      - On DC#2 prestage the subcloud for software deploy.
      - Verify that the 24.09 release is prestaged on the subcloud.

PASS: - Bring up a DC#1 with 24.09 and at least 1 subcloud.
      - Bring up a DC#2 with 24.09 pre-patched load.
      - Rehome subcloud from DC#1 to DC#2.
      - On DC#2 prestage the subcloud for software deploy.
      - Verify that the 24.09 release is prestaged on the subcloud.

Story: 2010676
Task: 51037

Change-Id: I7c2a985972df57b18b9ddcff4ac9d6ffd0d10e8e
Signed-off-by: Cristian Mondo <cristian.mondo@windriver.com>
2024-10-03 15:27:32 -03:00
2019-06-15 14:03:07 -05:00
2023-04-28 12:38:49 -04:00
2019-06-15 14:21:19 -05:00
2019-06-15 14:21:19 -05:00

stx-ansible-playbooks

StarlingX Bootstrap and Deployment Ansible1 Playbooks

Execution environment

  • Unix like OS (recent Linux based distributions, MacOS, Cygwin)
  • Python 3.8 and later

Additional Required Packages

In addition to the pakages listed in requirements.txt and test-requirements.txt, the following packages are required to run the playbooks remotely:

  • python3-pexpect
  • python3-ptyprocess
  • sshpass

Supported StarlingX Releases

The playbooks are compatible with StarlingX R8.0 and later.

Executing StarlingX Playbooks

Bootstrap Playbook

For instructions on how to set up and execute the bootstrap playbook from another host, please refer to the StarlingX Documentation2, at Installation Guides, section Configure controller-0 of the respective system deployment type.

Developer Notes

This repository is not intended to be developed standalone, but rather as part of the StarlingX Source System, which is defined by the StarlingX manifest3.

References


  1. https://docs.ansible.com/ansible/latest/installation_guide↩︎

  2. https://docs.starlingx.io↩︎

  3. https://opendev.org/starlingx/manifest.git↩︎

Description
StarlingX Ansible Playbooks
Readme 30 MiB
Languages
Jinja 70.3%
Python 21.4%
Shell 8.2%