...
ONAP Initial identities fictitiously a euphemistic hierarchy. Obviously, a real company would want to replace this with their own.
identity.dat
This file is store in the Repository (starting from authz, see above clone)
| Code Block | ||||
|---|---|---|---|---|
| ||||
auth/sample/data/sample.identities.dat |
When deployed, you will find the file "identities.dat" in docker directories "/opt/app/osaaf/data", and a configured Docker Volume of "config". (The Docker Volume keeps this file up persistently, whether Apps exist or not).
Before each AAF Docker component is launched, it is preceded by "aaf-config" init-container. The aaf-config init-container, among other things:
checks to see if the "identities.dat" file exists.
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.
* 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.
** If this is too much work, they are free to update the "identities.dat" file from their own Organization information on a timely basis.
*** 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.
Relationship to various ONAP Test environments:
ONAP Test Environment typically start off from scratch. In some cases, every day. This validates that all ONAP could start, as a System, from scratch.