libamxs
0.6.0
Data Model Synchronization C API
|
The goal of this library is to provide an API that makes it possible to keep information in sync between two data models
You could install all tools needed for testing and developing on your local machine, but it is easier to just use a pre-configured environment. Such an environment is already prepared for you as a docker container.
Install docker
Docker must be installed on your system.
If you have no clue how to do this here are some links that could help you:
Make sure you user id is added to the docker group:
``` sudo usermod -aG docker $USER ```
Fetch the container image
To get access to the pre-configured environment, all you need to do is pull the image and launch a container.
Pull the image:
```bash docker pull registry.gitlab.com/soft.at.home/docker/oss-dbg:latest ```
Before launching the container, you should create a directory which will be shared between your local machine and the container.
```bash mkdir -p ~/amx_project/libraries/ ```
Launch the container:
```bash docker run -ti -d –name oss-dbg –restart always –cap-add=SYS_PTRACE –sysctl net.ipv6.conf.all.disable_ipv6=1 -e "USER=$USER" -e "UID=$(id -u)" -e "GID=$(id -g)" -v ~/amx_project/:/home/$USER/amx_project/ registry.gitlab.com/soft.at.home/docker/oss-dbg:latest ```
The -v
option bind mounts the local directory for the ambiorix project in the container, at the exact same place. The -e
options create environment variables in the container. These variables are used to create a user name with exactly the same user id and group id in the container as on your local host (user mapping).
You can open as many terminals/consoles as you like:
```bash docker exec -ti –user $USER oss-dbg /bin/bash ```
Dependency graph - libraries needed by libamxs. For graph simplicity direct dependencies which are also an indirect dependency are not shown.
graph TD; libamxs-->libamxb-->libamxd-->libamxp-->libamxc
Clone the git repository
To be able to build it, you need the source code. So open the directory just created for the ambiorix project and clone this library in it (on your local machine).
```bash cd ~/amx_project/libraries/ git clone git@g:prpl-foundation/components/ambiorix/libraries/libamxs.git ``` itla b.com
Install dependencies
Although the container will contain all tools needed for building, it does not contain the libraries needed for building libamxs
. To be able to build libamxs
you need libamxc
, libamxp
, libamxb
and libamxd
. These libraries can be installed in the container.
```bash sudo apt update sudo apt install libamxb ```
Note that you do not need to install all components explicitly. Some components will be installed automatically because the other components depend on them. Some of the components are allready preinstalled in the container.
Build it
When using the internal gitlab, you must define an environment variable VERSION_PREFIX
before building.
```bash cd ~/amx_project/libraries/libamxs make ```
Build Documentation (optional)
```bash cd ~/amx_project/libraries/libamxs make doc ```
The documentation will be available in the directory ./output/doc/doxy-html
. The generated documenation can be viewed in your favorite browser, open the file index.html
.
You can install your own compiled version easily in the container by running the install target.
From within the container you can create packages.
The packages generated are:
You can copy these packages and extract/install them.
For ubuntu or debian distributions use dpkg:
Install dependencies
Most of the packages needed for testing are allready preinstalled in the container. To be able to test libamxs
you need to extra install libamxo
.
```bash sudo apt update sudo apt install libamxo ```
Run tests
You can run the tests by executing the following command.
```bash cd ~/amx_project/libraries/libamxs/tests make ```
Or this command if you also want the coverage tests to run:
```bash cd ~/amx_project/libraries/libamxs/tests make run coverage ```
The coverage target will generate coverage reports using gcov and gcovr.
A summary for each file (*.c files) is printed in your console after the tests are run. A HTML version of the coverage reports is also generated. These reports are available in the output directory of the compiler used. Example: using native gcc When the output of gcc -dumpmachine
is x86_64-linux-gnu
, the HTML coverage reports can be found at ~/amx_project/libraries/libamxs/output/x86_64-linux-gnu/coverage/report.
You can easily access the reports in your browser. In the container start a python3 http server in background.
Use the following url to access the reports http://<IP ADDRESS OF YOUR CONTAINER>:8080/libraries/libamxs/output/<MACHINE>/coverage/report
You can find the ip address of your container by using the ip
command in the container.
Example:
in this case the ip address of the container is 172.17.0.7
. So the uri you should use is: http://172.17.0.7:8080/libraries/libamxs/output/x86_64-linux-gnu/coverage/report/
This library provides functions to make it easy to synchronize parts of a data model with each other.
Synchronize legacy data models with standardized data model:
The standard data models evolve and often data model part were implemented before they were available in the BBF standards. When the standard is adapted it is often not in-line with what was already implemented. To be able to quickly adapt to the updated standard it is often sufficient to define the standard data model and set-up synchronization between them.
NOTE Most of the time this is a temporary solution, in the end the legacy data model should be replaced with the standard data model. The synchronization provides a way to create a transition period were the legacy data model is still used, but declared deprecated until all other applications are switched to the standard data model.
—
Prefixed objects and parameters:
Often vendor specific parameters are added to standard data model definitions to be able to add extra functionality or keep track of some internal state. These parameters are prefixed with a vendor specific identifier. One of the problems with these prefixes is that they can change in the future or these extra objects and parameters get standarized, so the prefix must be removed. Other applications that depend on these non-standardized objects and parameters must be updated each time that happens, which is a huge maintenance task that must be avoided at all costs. Using synchronization it is possible to define objects and parameters without the prefix and the same with the prefix. The ones without the prefix must be not visible to external applications (like USP-controlles, webui, ...) and therefor should be defined protected.
The following diagrams show some of the possible combinations of synchronization, but it is not limited to these combinations. Other combinations are possible, these are the most common ones.
Objects and parameters that are defined in the same data model can be synchronized with each other.
flowchart subgraph Process subgraph Datamodel objectA <--> Synchronization <--> objectB end end style Datamodel fill:#888
NOTE The above synchronization can update read-only parameters in objectA and objectB
—
Objects and parameters that are defined in different data models can be synchronized with each other. The synchronization implementation must be done in only one of the processes (not in both).
flowchart LR subgraph ProcessA subgraph DatamodelA objectA end Synchronization end subgraph ProcessB subgraph DatamodelB objectB end end objectA <--> Synchronization <--> objectB style DatamodelA fill:#888 style DatamodelB fill:#888
NOTE The above synchronization can update read-only parameters in objectA
—
flowchart LR subgraph ProcessA subgraph DatamodelA objectA end end subgraph ProcessB subgraph DatamodelB objectB end Synchronization end objectA <--> Synchronization <--> objectB style DatamodelA fill:#888 style DatamodelB fill:#888
NOTE The above synchronization can update read-only parameters in objectB
—
Objects and parameters that are defined in different data models can be synchronized with each other. The synchronization implementation can be done in a separate processes
flowchart LR subgraph ProcessA subgraph DatamodelA objectA end end subgraph ProcessB subgraph DatamodelB objectB end end subgraph ProcessC subgraph Synchronization end end objectA <--> Synchronization <--> objectB style DatamodelA fill:#888 style DatamodelB fill:#888
NOTE The above synchronization can not update any read-only parameters
—
Creating a synchronization context is easy:
amxs_sync_ctx_new
or amxs_sync_ctx_init
.amxs_sync_object_new
, amxs_sync_object_new_copy
, amxs_sync_param_new
or amxs_sync_param_new_copy
.amxs_sync_ctx_add_object
, amxs_sync_ctx_add_param
, amxs_sync_object_add_param
, amxs_sync_object_add_object
.amxs_sync_ctx_start_sync
.NOTE
Other functions exist to make it easier to create synchronization context. Check the API documentation to find out more details about the available functions.
—
Consider this data model definition in odl format:
To create a full synchronization between object A.
and B.
the following code is needed:
amxs_sync_ctx_set_local_dm
must be called to set the local data model on the synchronization context.