Accidental heal to wrong version
If the csar heal command is accidentally run with the wrong target SDF version, it will perform steps which are closely equivalent to a csar update to the new version, in other words an unplanned rolling upgrade.
In the case where the new total number of versions is 2, follow the usual rollback procedure described in this document to recover by rolling back the unplanned "upgrade", rolling back to the original version. This applies for example when all the other nodes are all on the same software version, or mid upgrade/rollback, when accidentally moving to other version.
If however, the group was already mid upgrade/rollback, and the node was healed to some third, different version, then this situation is not recoverable, and the group must be deleted and deployed again, using the procedure for deleting a VM group. See the Backout procedure within this guide for detailed steps on backing out the group.
The current versions can be queried using the rvtconfig report-group-status command.
Accidental redeploy to wrong version
If the csar redeploy command is accidentally run with the wrong target SDF version, the VM will detect this case, and refuse to converge.
This will be detectable via the output of the rvtconfig report-group-status command
The initconf.log file on the machine will indicate this case, failing fast by design.
To recover from this case, use csar redeploy to redeploy back to the original version, using the normal csar redeploy procedure detailed on the previous pages.
