| Jira Legacy | ||||||||||
|---|---|---|---|---|---|---|---|---|---|---|
|
We install ONAP several times a day in our different CI/CD chains however we always resinstall a new ONAP.
The Backup&Restore feature is a MUST HAVE for production, it may be invoked for different levels of B&R and different associated tests:
| Type of B&R | Description | Comments | Type |
|---|---|---|---|
| Disaster Recovery | Your ONAP is corrupted, despite of brilliant tricks, you are not able to re-enable it You reinstall a new ONAP (same version) and restore everything you can.. | Downtime is acceptable Restart of component is acceptable Basically everything is acceptable as the first ONAP is no more usable... Reinstallation is a fresh reinstallation (with new passwords) | Full |
| Iso version Migration | Your ONAP is running well but for any reasons (capability, fun, ..) you want to switch and need a new ONAP (same version) You install ONAP' on a new infrastructure You freeze ONAP you backup ONAP you restore on ONAP' you switch from ONAP to ONAP' | No Downtime | Full |
ONAP Active/Standby Belts and Braces | You are richn you have an ONAP in production and another ONAP in case the first one crashes. You need to regularly resync the stanby ONAP | No Downtime | Differential/Mirror |
| Smooth Full Upgrade | You want to move from version N to version N+1 and keep all your services/VSP/VF, SO history/Loop/... You install a version N+1 in // of version N You freeze your version N, save everything you can You restore N on N+1 You switch from N to N+1 | No Downtime Possible compatibility issues...infra, k8, ONAP API Not it is possible to upgrade 1 component by editing the deployment...but it is out of scope event if a test could be also interesting | Incremental |
| Wild Upgrade | Same than Upgrade but between 2 consecutive versions (LTS versions) | No Downtime compatibility issues ++ | Incremental |
3 or 4 types of Backup are usually defined:
...