== DECRIPTION == 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. == DOCS IMPACT == Requires documentation in the Troubleshooting section of the Upgrade Guide
Hi Dan, this won't make it to osp12 and is reported for osp13, so I guess this can be closed. Thanks,
Moving to OSP13 as per Sofer's comment
Sofer and Carlos, Do we still need an action on this item? My understanding is the new "openstack overcloud upgrade" command can essentially be rerun and using specific node roles or hostname (due to Ansible). Is that the case? Do we need any further documentation on this item?
Hi Dan, (In reply to Dan Macpherson from comment #3) > Sofer and Carlos, > > Do we still need an action on this item? My understanding is the new > "openstack overcloud upgrade" command can essentially be rerun and using > specific node roles or hostname (due to Ansible). Is that the case? Do we > need any further documentation on this item? No, I think we're good with the current workflow and this bz can closed. One thing, though, is that we don't test for idempotency of the task run during upgrade. So even if we can now rerun any role/host, it may fail because we didn't check that all tasks are idempotent. But that's another story.