MariaDB does not officially supports downgrade between major versions [1]. When the update fails and the application framework tries to roll-back the STX-O deployment, the recovery fails in the MariaDB Helm chart. The solution for this is first, when the update fails it will trigger the deletion of the updated MariaDB Helm release. The other step will be to have the persistentvolume to the old MariaDB backed up at the beggining of the update, and if the update fails, it will trigger a function that will remove the persistentVolume from the new MariaDB and replace with the old one. this work is going to to be maped to the task 51826 in the storyboard: https://storyboard.openstack.org/#!/story/2011262 This review aims to address the first part of the solution, where the MariaDB Helmrelease is deleted before starting the recovery process. It was necessary to create a function do delete the Helmrelease as it was noted that the new MariaDB could be redeployed by FluxCD reconciliation, before the old one, if it was opted to only uninstall the Helmrelease. Test Plan: PASS - Build python3-k8sapp-openstack PASS - Build WRO PASS - Force an update fail and check if MariaDB Helmrelease is deleted Relates-To: https://review.opendev.org/c/starlingx/openstack-armada-app/+/945094/6 Both reviews on the relation chain should be merged together as it functions as one to MariaDB be able to rollback in case of failed update. [1] - https://mariadb.com/kb/en/downgrading-between-major-versions-of-mariadb/ Story: 2011262 Task: 51787 Change-Id: I60b009c805673d00d54b1c4ff8c868cd8f2f0190 Signed-off-by: Daniel Caires <DanielMarques.Caires@windriver.com>
k8sapp-openstack
This project contains StarlingX Kubernetes application specific python plugins for the openstack application. These plugins are required to integrate the openstack application into the StarlingX application framework and to support the various StarlingX deployments.