From: Francisco-Javier Ramón Salguero Date: Mon, 4 Feb 2019 03:00:06 +0000 (+0100) Subject: Full exposure of internal RO runtime data to common OSM database X-Git-Url: https://osm.etsi.org/gitweb/?a=commitdiff_plain;h=refs%2Fchanges%2F84%2F7184%2F2;p=osm%2FFeatures.git Full exposure of internal RO runtime data to common OSM database Change-Id: If2f59f79672a3c6057b92ea9bee421e20592aaac Signed-off-by: Francisco-Javier Ramón Salguero --- diff --git a/Release6/Full exposure of internal RO runtime data to common OSM database.md b/Release6/Full exposure of internal RO runtime data to common OSM database.md new file mode 100644 index 0000000..1dfc4c6 --- /dev/null +++ b/Release6/Full exposure of internal RO runtime data to common OSM database.md @@ -0,0 +1,45 @@ +# Full exposure of internal RO runtime data to common OSM database + +## Proposer + +- Gerardo Garcia (Telefonica) +- Alfonso Tierno (Telefonica) +- Francisco Javier Ramon (Telefonica) + +## Type + +**Feature** + +## Target MDG/TF + +RO, LCM + +## Description + +Currently all runtime information related to resources is keep in an internal +database in RO, which is partially replicated in the common database, involving +a translation of models and storage mechanisms. This is inefficient for several +reasons: + +- RO-related information stored in the common database is not authoritative, +but a copy of the real authoritative info (information is duplicated). +- Therefore, there is no 100% guarantee that the info in the common databases +is kept in sync with the actual authoritative database. +- There is a translation in place, to adapt the information to the different +database paradigms (relational vs. noSQL) and map to to system-level IDs and +objects. +- Almost all changes at IM trigger a specific development to change the +relational RO database and to make the appropriate translations. This usually +requieres extensions in RO´s northbound interface capabilities too. +- Maintaining this duplicate mechanism makes RO development and evolution +artificially complex with no obvious advantages. + +Hence this feature requests the direct use of common OSM services by RO +(particularly, the common database) so that information is always up to date +and RO's maintenance is largely simplified, being current legacy RO's NBI and +translation mechanisms no longer needed. + +## Demo or definition of done + +Check that all information of state in RO is always available in the common +NoSQL databes, and that internal RO's MySQL database can be safely removed.