1f50e74540
When the rook-ceph application upgrade/downgrade was aborted, the
storage-backend remained stuck in the "updating" state. This happened
because 'kube_app' did not trigger a lifecycle hook after the
application recovery process completed (fixed through the depends-on
review). As a result, the rook-ceph lifecycle could not proceed to
update the storage-backend.
These changes allow the update_backend to be executed only once in each
application lifecycle actions and use the new trigger after the
recovery proccess to keep the storage backend updated.
TEST PLAN:
- PASS: Build an image and perform a fresh install.
- PASS: Perform a lab upgrade, and check the storage-backend task
- PASS: Perform a lab rollback, and check the storage-backend task
- PASS: Apply the rook-ceph app and check if the storage-backend task
is following the rook-ceph app status
- PASS: Reapply the rook-ceph app and check if the storage-backend task
is following the rook-ceph app status
- PASS: Upgrade the rook-ceph app and check if the storage-backend task
is following the rook-ceph app status
- PASS: Downgrade the rook-ceph app and verify the storage-backend
remains in the 'applied' state.
- Downgrade the rook-ceph app and abort the action, and check:
- PASS: If the storage-backend is updated to 'updating' when the
abort command is performed.
- PASS: If the storage-backend is updated to 'applied' when the app
is recovered.
Depends-On: https://review.opendev.org/c/starlingx/config/+/962181
Closes-bug: 2125607
Change-Id: Idc6e126ffce024e24a2f2eb665a65a20c8813a01
Signed-off-by: Gustavo Ornaghi Antunes <gustavo.ornaghiantunes@windriver.com>
k8sapp_rook_ceph
This project contains StarlingX Kubernetes application specific python plugins for the rook ceph application. These plugins are required to integrate the application into the StarlingX application framework and to support the various StarlingX deployments.