...
If not, it copies it from "/opt/app/aaf_config/data/sample.identities.dat" in the aaf-config Docker Image, and places it at /opt/app/osaaf/data/identities.dat, which is on the Persistent Docker Volume "config", as noted.
This ensures that identities.dat only starts new when it doesn't exist, and DOESN'T overwrite work that Companies may be doing. Being in the "aaf-config" image avoids size implications in the other components.
* This "identities.dat" file is utilized exclusively by the "DefaultOrganization". Companies are welcome and encouraged, if they wish, to create their own "Plugin that implements the 'Organization' interface", and connects to their own data how they please.
...
*** Companies should note that this mechanism was written for an ONAP member company with a nightly feed that included more than 1.3 million records. It does so very efficiently, without synchronizing data.
Cassandra Data:
Cassandra data, that is interrelated to the above "Identities" and each other also need enough data to be functional with all the ONAP apps required.
In the repo, these files (ending in ".dat") are found at
| Code Block | ||||
|---|---|---|---|---|
| ||||
auth/sample/cass_data |
Included here are the ESSENTIAL data files in Cassandra (other Cassandra Data files are fine to be empty at the beginning, i.e. the history data).
Similarly to the identity file, the Cassandra Docker keeps the INIT files in a docker image, but as opposed to AAF Components, it simply keeps them in the aaf-cass docker image.
IF the container, when starting, finds that cassandra tables are not defined, THEN the container will initialize cassandra from "cql" files located in the image at "/opt/app/aaf/cass_init " (copied from the repo directory auth/auth-cass/cass_init). The container executes "keyspace.cql", "init.cql", "temp_identity.cql" and "onap.cql" to setup the initial tables.
IF the image finds that the cassandra tables are uninitialized THEN the image will load the data from the docker image directory "/opt/app/aaf/cass_init/". It does NOT initialize if the data exists, so as not to overwrite running systems.
Please see repo "auth/auth-cass/cass_init/cmd.sh" to see how this is accomplished.
Relationship to various ONAP Test environments:
ONAP
...
Testing typically start off "from scratch", which means that there is no existing implementation or configuration. In some cases, every day. This validates that all ONAP could start, as a System, "from scratch", and gives a clean environment for various tests.
AAF utilizes the above Configurations mechanisms to ensure that each brand-new environment for ONAP starts off with existing Data. This includes NEW ONAP components, documented in "sample.identities.dat" and the Permissions and Roles (etc) that the Apps create within the AAF Test system.
As described above, all the Identities and Data are pushed into Containers (init or otherwise), which can start up and configure when data does not exist, or avoid overwriting when they do exist.