1 # Full exposure of internal RO runtime data to common OSM database
5 - Gerardo Garcia (Telefonica)
6 - Alfonso Tierno (Telefonica)
7 - Francisco Javier Ramon (Telefonica)
19 Currently all runtime information related to resources is keep in an internal
20 database in RO, which is partially replicated in the common database, involving
21 a translation of models and storage mechanisms. This is inefficient for several
24 - RO-related information stored in the common database is not authoritative,
25 but a copy of the real authoritative info (information is duplicated).
26 - Therefore, there is no 100% guarantee that the info in the common databases
27 is kept in sync with the actual authoritative database.
28 - There is a translation in place, to adapt the information to the different
29 database paradigms (relational vs. noSQL) and map to to system-level IDs and
31 - Almost all changes at IM trigger a specific development to change the
32 relational RO database and to make the appropriate translations. This usually
33 requieres extensions in RO´s northbound interface capabilities too.
34 - Maintaining this duplicate mechanism makes RO development and evolution
35 artificially complex with no obvious advantages.
37 Hence this feature requests the direct use of common OSM services by RO
38 (particularly, the common database) so that information is always up to date
39 and RO's maintenance is largely simplified, being current legacy RO's NBI and
40 translation mechanisms no longer needed.
42 ## Demo or definition of done
44 Check that all information of state in RO is always available in the common
45 NoSQL databes, and that internal RO's MySQL database can be safely removed.