Skip to content

Internal Information Model

Internal Information Model

Proposers

Eduardo Sousa eduardo.sousa@canonical.com David Garcia david.garcia@canonical.com Mark Beierl mark.beierl@canonical.com Fabian Bravo fbravo@whitestack.com Subhankar Pal subhankar.pal@aricent.com

Type

Feature

Target MDG/TF

common

Impacts

NBI, LCM, RO, MON, POL. PLA, N2VC

Description

The objective of this feature is the introduction of an internal information model that defines the structure of the database schema (what collections are used and what fields are in each kind of document). It provides data structure independent from the external information model, meaning that module development is linked to the internal model and not to the external information model.

Being decoupled from the external information model requires a translation layer from the external information model to the internal information model. This translator should identify the external information model version and translate it to the current internal information model.

Since the internal information model will vary slightly during its existence it's necessary to have migrations of the DB from the previous to the next version. This should be done in the form of small scripts that should be run whenever a migration is required. These scripts need to be documented and have tests.

Finally, this change is to benefit developers work, therefore it should ease their lifes in the development process. This library includes data access objects to provide programatic access to this data. So, model objects should be created to transpose data in the data store into python objects, allowing for code inspection that doesn't involve checking data store structure or checking all the other modules that might change the data.

Demo or definition of done

The definition of done for this feature is the following:

  1. Data schema documentation - information indicating how the mapping is done between the different external information models and the internal information model. This includes collections used and fields.
  2. Translator - translation code in order to translate from external to internal model.
  3. Python data access objects - these objects are meant to be used by the different modules to access the data and manipulate it. This should include module documentation and unit tests. This includes a loader class to load objects from the data store.
  4. Migration scripts - scripts to migrate the data store from the old version to the new one. This should include documentation and tests to make sure that migration is working properly.
  5. Documentation - everything should have proper documentation, in order to make adoption faster and proper decisions can be made.