Description of problem: Currently (as of OSP 13) the Control Plane Backup procedure is a documented manual procedure. The use case for this procedure is limited to Fast Forward Upgrades (FFU) that upgrade OpenStack controllers from one long life version to another (e.g. OSP 10 to OSP 13). There is a playbook for backup in Ansible, which has not been tested as part of the product which automates the manual steps for backup. There is currently no automated procedure for backup. The current manual procedure is focused exclusively on the FFU use case and a limited configuration of 3 controllers. The procedure for restore from a backup is also not automated, and is a series of documented manual steps. The backup and restore will happen on the same version (major & minor) of RHOSP. We need to extend the manual procedure so that it includes more standard configurations as used by customers. One those manual procedures are in place playbooks in Ansible need to be created/updated and packaged in the appropriate place (which is tripleo-ansible - just recently introduced upstream) Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. 2. 3. Actual results: Expected results: Additional info:
Juan,can you,please,provide instructions for QA.
Ensure that the automate backup process does the same as the manual one. On the tests the backup needs to be done automatically and the restoration manually, Then the following needs to be verified: - Ensure that the restored platform is working and operators can do their daily basis. In my opinion tempest will do. - Ensure that the VMs on the computes were not affected on the B&R process. - Ensure that the restored platform is able to upgrade to the next release.
Since the problem described in this bug report should be resolved in a recent advisory, it has been closed with a resolution of ERRATA. For information on the advisory, and where to find the updated files, follow the link below. If the solution does not work for you, open a new bug report. https://access.redhat.com/errata/RHEA-2019:2811