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>
1f50e74540