StarlingX Ansible Playbooks
aeabb62d84
This commit addresses two issues observed during enrollment: one with OAM reconfiguration and another with management network configuration. 1. OAM Reconfiguration Conflict: With OAM reconfiguration, manifests may be deferred to later stages of enrollment and applied multiple times, ultimately conflicting with the enrollment process. Specifically, updating the OAM network triggers Puppet to apply the class openstack::keystone::endpoint::runtime::post based on stale config, which may reset the updated Keystone user passwords, causing service failures. This commit introduces an enrollment_in_progress flag, preventing the openstack::keystone::endpoint::runtime Puppet class from running during enrollment (see related Puppet changes[1]). 2. Management Network Reconfiguration: When the management network is updated, certs are updated with the new address. However, endpoints are only fully reconfigured after unlock. This leads to a transitional state where endpoints still use the old IP, causing failures as certificates reference the new IP. To address this, we bypass certificate validation during enrollment. The central cloud will not validate the certificates presented by the subcloud during enrollment's transitional state. [1] https://review.opendev.org/c/starlingx/stx-puppet/+/938062 Test plan: Run end-to-end enrollment, ensuring subcloud is fully enrolled (endpoints reconfigured, no alarms reported, etc) and reporting online in system controller Following tests were done in both Virtual and H/W Lab: PASS: No network reconfiguration. Enroll with same network config set during inital install. PASS: OAM network reconfiguration. Enroll with a different OAM IP that's set during inital install. PASS: Mgmt. network reconfiguration. Enroll with a different Mgmt. IPs that's set during inital install. PASS: Run common roles with 'rehome' mode, ensure cert checks are done. PASS: Verify enrollment with retry. Run enrollment with induced failure, revert the failure and retry. Ensure successful end-to-end enrollment. Closes-bug: 2092214 Closes-bug: 2092212 Change-Id: Ie416009dfbc52702c4cb884e474e32da76d4d7eb Signed-off-by: Salman Rana <salman.rana@windriver.com> |
||
|---|---|---|
| examples | ||
| playbookconfig | ||
| .ansible-lint | ||
| .gitignore | ||
| .gitreview | ||
| .yamllint | ||
| .zuul.yaml | ||
| CONTRIBUTORS.wrs | ||
| debian_build_layer.cfg | ||
| debian_iso_image.inc | ||
| debian_pkg_dirs | ||
| LICENSE | ||
| README.rst | ||
| requirements.txt | ||
| test-requirements.txt | ||
| tox.ini | ||
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.