From 369bf38ef1db0c1b758cb289aa7a629c80e68264 Mon Sep 17 00:00:00 2001 From: garciadeblas Date: Wed, 29 Mar 2017 23:56:57 +0200 Subject: [PATCH 1/1] OSM platform recovery after major failure Change-Id: I2e790e689cf4f8c5903ab9967d114d24b17a359b Signed-off-by: garciadeblas --- ...M_platform_recovery_after_major_failure.md | 39 +++++++++++++++++++ 1 file changed, 39 insertions(+) create mode 100644 Release5/OSM_platform_recovery_after_major_failure.md diff --git a/Release5/OSM_platform_recovery_after_major_failure.md b/Release5/OSM_platform_recovery_after_major_failure.md new file mode 100644 index 0000000..f966e33 --- /dev/null +++ b/Release5/OSM_platform_recovery_after_major_failure.md @@ -0,0 +1,39 @@ +# OSM platform recovery after major failure # + +## Proposer ## +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type ## +**Feature** + +## Target MDG/TF ## +SO, RO, VCA, UI + +## Description ## +**This feature obsoletes feature #666: +https://osm.etsi.org/gerrit/#/c/666/** + +The NFV Orchestrator becomes a critical component for the operator in a +production environment. As such, it should be capable of recovering from +unexpected failures of its components. In case of a major failure, it should be +able to restore its last known internal state after an unexpected system +shutdown. + +As part of this recovery strategy it might be useful identifying: +- Which sub-components (inside each of the current modules) are intended to +store permanent information (databases, repositories) or should be considered +stateful. +- Which sub-components are stateless (or can recover efficiently their state +from databases or stateful components) and devise bootstrap procedures for them. +- The flow by which databases and the state of the different components should +be recovered after a crash. +- If applicable, the restart sequence of the modules after a crash, i.e. if +they need to be started in a specific order. + +## Demo or definition of done ## +In a running OSM system with an instantiated NS, an abrupt shutdown of all the +OSM components is forced (e.g. of the VM/host); then, the system is restarted +and recovers the last known state, allowing OSM to operate the pre-existing NS +instance again. \ No newline at end of file -- 2.25.1