As a cloud operator, in case of failed upgrade I want to revive whenever it is possible and continue in the process (or start it from beginning) without need to rollback my environment to previously working state.
Service upgrade should be idempotent, we are trying to achieve a goal:
"If updates fail, I want to re-run upgrade command, which will revive the procedure and ends the process (this time hopefully) successfully."
Comment 4Sofer Athlan-Guyot
2017-05-30 12:28:49 UTC
Need a associated test plan for QE if possible.
Comment 5Sofer Athlan-Guyot
2017-06-22 12:43:12 UTC
Hi,
This would need to be requalified into more manageable RFE and delayed for next release.
The split could go like this:
- ensure deployment idempotency by testing it: this is an upstream discussion about testing this backup: http://lists.openstack.org/pipermail/openstack-dev/2017-June/117968.html
- ensure upgrade idempotency by testing it: following up with the previous work we could ensure that upgrading twice in a raw doesn't cause any problem
With those tests in place we can have a vision of what is missing and fixing the associated issues.
The last steps are:
- add testing failure during upgrade and check we can recover easily:
- not everything can be tested, but a error in the major step of the upgrade
- review all upgrade code to check if idempotency is achieved all the time;
Comment 10Sofer Athlan-Guyot
2018-08-22 16:53:06 UTC
To be revive in a new RFE when that becomes relevant again.