6793f3840f
This commit resolves an issue seen when attempting to upgrade / patch from a previous StarlingX release to the current StarlingX development load in which the distributed cloud admin network feature is present. 1. Currently, the admin-services SM service group is created if the system is detected to be a subcloud. This presents a problem during upgrade, because the <N> system has no concept of the admin-services group, while the upgraded <N+1> system does. During upgrade when the system is swacted to the <N+1> system, an alarm will be raised as the <N> system has no admin-services group (designed to be an N+M redundancy model). 2. A potential solution to the above problem is to only provision the admin-services group if an operator has actually configured an admin interface / network after the full upgrade has completed. However, this presents the same sort of problem, as an interface-network association is done on a host-by-host basis, requiring a lock of each host to provision a new admin interface. Since there is no mechanism to provision a new SM service group at runtime, this leads to the same situation of one host being aware of the admin-services group, while the other does not. That is, a user might configure and admin inteface-network on host <X>, but the service group would not be present on host <Y>, leading to the same alarm. The solution here is to do away with the new admin-services service group, and leverage the existing controller-services group for the admin-ip service. Test-Plan: - Ensure no alarms when upgrading / patching a subcloud implementing the admin network feature. - Ensure a system utilizing the admin network can become online / in-sync. - Swact between controllers utilizing the admin-ip SM service to ensure the floating IP is correctly assigned to the active controller (using the controller-services service group). Regression: - Install a DC system using the management network. Create the admin interface, network on the subcloud and ensure a user can update the subcloud to use the admin network. Story: 2010319 Task: 47278 Change-Id: Ic36e83622c6ab5d15fd537be69d3314cb675c724 Signed-off-by: Steven Webster <steven.webster@windriver.com> |
||
|---|---|---|
| api-ref/source | ||
| devstack | ||
| doc | ||
| releasenotes | ||
| service-mgmt | ||
| service-mgmt-api | ||
| service-mgmt-client | ||
| service-mgmt-tools | ||
| stx-ocf-scripts | ||
| .gitignore | ||
| .gitreview | ||
| .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_stable_wheels.inc | ||
| debian_build_layer.cfg | ||
| debian_iso_image.inc | ||
| debian_pkg_dirs | ||
| github_sync.trigger | ||
| pylint.rc | ||
| test-requirements.txt | ||
| tox.ini | ||
README.rst
ha
The starlingx/ha repository handles High Availability services1.
Its key component is the StarlingX Service Management (SM), which coordinates the StarlingX services.
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.