What is the process to revert to a previous version of the OS? Our new change control process requires a rollback plan. Which means I need to document the process to roll back to the previous version of the OS.
To my knowledge, and having worked with several storage products over the years, the only time I have seen OS downgrades available/supported is when the systems do not contain data, or the customer agrees that the data is not required. e.g. they are brand-new, were shipped with a later version than a customer's current standard, and they want to down-level to that version vs. forcing an upgrade.
The reason why this is often only supported on empty arrays is that the process would likely be data destructive, and so would need to be followed by a recovery from a backup. This could obviously be a lengthy process depending on the size of the system.
If you can provide additional detail about what your process requires, and what risks you are trying to mitigate, we would be glad to evaluate some other options with you.
Rollback of a Nimble OS upgrade would not be a normal course of action. There are several safeguards and checks that are built in to the upgrade process to mitigate the chances of upgrades failing, and therefore also mitigating the need for rollback.
Firstly - Unlike most other vendors, we use InfoSight to check your configuration and validate that there are no known issues that could cause your upgrade to fail. Once this has occurred, your array would be whitelisted to receive a new version. If issues were detected, your array would be blacklisted from downloading that version.
Secondly - After you have downloaded a whitelisted version of Nimble OS, and select to perform the upgrade, we perform a system health check. This must pass successfully for the upgrade to continue. This ensures things like the network etc. are in good shape before we move forward to the next stage.
Thirdly - We start the upgrade of the standby controller to the new version, and reboot to this code level to validate that the upgrade on that controller has been successful. Once that has been completed, we then upgrade the active controller to the new version of code. On reboot of the active controller, this is when the data path switches to previously standby controller, and it becomes active.
While all this is happening, we are still monitoring the heartbeats of the array, so if the process takes longer than expected or you run into some other problems we know right away.
Lastly, if any issues do arise, we recommend you engage with our 24 hr support team as the first action. If they cannot resolve the issue, we escalate to engineering for a roll forward plan. This might involve a patch or configuration change to get you back up and running as quickly as possible.
Thanks for the info, however it doesn't satisfy my need to document the roll back procedures for our change control process.
Retrieving data ...