Skip to end of metadata
Go to start of metadata
You are viewing an old version of this page. View the current version.
Compare with Current
View Page History
« Previous
Version 26
Next »
Contributors
Glossary
| Term | Definition |
|---|
| AAI-internal-clients | Sub-projects of AAI that are direct clients of schema services (currently have dependency on aai-schema-ingest library) including: - data-router, gizmo, resources, router-core, sparky-be, spike, traversal, validation
Sub-projects of AAI that are indirect clients of schema services (via aai-common library) or are schema-agnostic including: - babel, cacher, chameleon, champ, eis, enricher, esr, gallifrey, graphadmin, graphgraph, logging-service, model-loader, rest-client, search-data-service, sparky-fe, tabular-data-service
|
| ONAP-project-clients | Projects of ONAP that are definitely clients of AAI including: Projects of ONAP that are likely clients of AAI including: - CLAMP, DMaaP, ExtAPI, Holmes, MSB, MultiVIM, OOM, Policy, Portal, SDC, SO, SDNC, VFC, VNFSDK, UUI
|
| producer-consumer pairings | Apart from "internal" AAI data, the data in AAI is produced by a non-AAI component and then consumed by another non-AAI component. Therefore the schema definitions and intended meanings of each schema element is not controlled by AAI itself. Example1 in "service-instance" the "input-parameters" attribute is a "String capturing request parameters from SO to pass to Closed Loop.", so it is an SO-to-CLAMP pairing. Example2 in
VFC-1193
-
Getting issue details...
STATUS
/
OPTFRA-268
-
Getting issue details...
STATUS
/
OPTFRA-291
-
Getting issue details...
STATUS
, there is an OOF-to-VFC pairing for this scenario: Example3 in https://lists.onap.org/g/onap-discuss/topic/openlab_vid_beijing_how/28275492, there is SDC-to-VID pairing for this scenario: - SDC distributes models into AAI
- Then VID calls custom query in AAI to get models by distribution status
- Finally VID uses models for its functions (this is the main flow for VID)
|
| deployment tools | Tools (e.g. Helm, ansible, Docker Compose, etc) used to: - place the microservices into their run-time environment
- distribute data files for initial configuration
- perform the initial configuration of microservices
- get the ONAP system running as intended
|
| IDL Files | Some form of "Interface Definition Language" which unifies and replaces the OXM files and EdgeRule files as definition of AAI schema |
| Purple highlights | Highlight change from predecessor ONAP Release |
References
Use Case Outlines
| ONAP Release Target | Use Case Summary | Deprecated Functions |
|---|
| Amsterdam, Beijing | AAI Schema is: - single-data-file configuration per version, i.e. one OXM file and one EdgeRule file
- distributed via source-code repository to AAI-internal-clients and ONAP-project-clients
- built into and deployed as microservice JAR file
- effective only upon microservice startup
|
|
| Casablanca | AAI Schema is: - multiple-data-file configuration, i.e. multiple OXM files and multiple EdgeRule files
- distributed via source-code repository to AAI-internal-clients and ONAP-project-clients
- built into and deployed as microservice JAR file
- effective only upon microservice startup
| - single-data-file configuration per version
|
| Dublin | AAI Schema is: - multiple-data-file configuration
- distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple OXM files and multiple EdgeRule files, without change to JAR files
- effective only upon AAI-internal-clients startup
- distributed as data files via deployment tools to AAI Schema Service, i.e. multiple OXM files and multiple EdgeRule files
- effective only upon AAI Schema Service startup
- distributed via run-time API to AAI-internal-clients
- effective only upon AAI-internal-clients startup
- distributed via source-code repository to ONAP-project-clients, i.e. XSD files and generated POJOs
- built into and deployed as ONAP-project-clients JAR file
- effective only upon ONAP-project-clients startup
| - single-data-file configuration per version
- distributed via source-code repository to AAI-internal-clients
- built into and deployed as microservice JAR file
|
| Dublin and beyond | Each of the AAI-internal-clients and ONAP-project-clients will need to identify the relevant pieces of AAI schema that relates uniquely to their operations. The multiple-data-file configuration to be grouped by producer-consumer pairings. |
|
| Dublin and beyond | Each of the AAI-internal-clients will need to decide when/how to proceed with changing over to the updated methods of distributing the AAI schema. |
|
| El Alto | AAI Schema is: - multiple-data-file configuration
- distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple OXM files and multiple EdgeRule files, without change to JAR files
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to AAI Schema Service, i.e. multiple OXM files and multiple EdgeRule files
- effective upon AAI Schema Service run-time refresh
- distributed via run-time API to AAI-internal-clients
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to ONAP-project-clients without change to JAR files
- effective only upon ONAP-project-clients startup
| - single-data-file configuration per version
- distributed via source-code repository to AAI-internal-clients
- built into and deployed as microservice JAR file
- effective only upon AAI Schema Service startup
- effective only upon AAI-internal-clients startup
- distributed via source-code repository to ONAP-project-clients
- XSD files and generated POJOs
|
| El Alto and beyond | Each of the ONAP-project-clients will need to decide when/how to proceed with changing over to the updated methods of distributing the AAI schema. |
|
| Frankfurt | AAI Schema is: - multiple-data-file configuration
- distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple IDL files, without change to JAR files
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to AAI Schema Service, i.e. multiple IDL files
- effective upon AAI Schema Service run-time refresh
- distributed via run-time SDC API to AAI Schema Service, i.e. multiple TOSCA files and CSAR files
- effective upon AAI Schema Service run-time refresh
- distributed via run-time API to AAI-internal-clients
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to ONAP-project-clients without change to JAR files
- effective only upon ONAP-project-clients startup
| - single-data-file configuration per version
- distributed via source-code repository to AAI-internal-clients
- built into and deployed as microservice JAR file
- effective only upon AAI Schema Service startup
- effective only upon AAI-internal-clients startup
- distributed via source-code repository to ONAP-project-clients
- XSD files and generated POJOs
- multiple OXM files and multiple EdgeRule files
|
| G release | AAI Schema is: - multiple-data-file configuration
- distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple IDL files or multiple TOSCA files and CSAR files, without change to JAR files
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to AAI Schema Service, i.e. multiple IDL files or multiple TOSCA files and CSAR files
- effective upon AAI Schema Service run-time refresh
- distributed via run-time SDC API to AAI Schema Service, i.e. multiple TOSCA files and CSAR files
- effective upon AAI Schema Service run-time refresh
- distributed via run-time API to AAI-internal-clients
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to ONAP-project-clients without change to JAR files
- effective only upon ONAP-project-clients startup
- distributed via run-time API to ONAP-project-clients
- effective only upon ONAP-project-clients startup
| - single-data-file configuration per version
- distributed via source-code repository to AAI-internal-clients
- built into and deployed as microservice JAR file
- effective only upon AAI Schema Service startup
- effective only upon AAI-internal-clients startup
- distributed via source-code repository to ONAP-project-clients
- XSD files and generated POJOs
- multiple OXM files and multiple EdgeRule files
|
| G release and beyond | Each of the ONAP-project-clients will need to decide when/how to proceed with changing over to the updated methods of distributing the AAI schema. |
|
| H release and beyond | AAI Schema is: - multiple-data-file configuration
- distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple IDL files or multiple TOSCA files and CSAR files, without change to JAR files
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to AAI Schema Service, i.e. multiple IDL files or multiple TOSCA files and CSAR files
- effective upon AAI Schema Service run-time refresh
- distributed via run-time SDC API to AAI Schema Service, i.e. multiple TOSCA files and CSAR files
- effective upon AAI Schema Service run-time refresh
- distributed via run-time API to AAI-internal-clients
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to ONAP-project-clients without change to JAR files
- effective upon ONAP-project-clients run-time refresh
- distributed via run-time API to ONAP-project-clients
- effective upon ONAP-project-clients run-time refresh
| - single-data-file configuration per version
- distributed via source-code repository to AAI-internal-clients
- built into and deployed as microservice JAR file
- effective only upon AAI Schema Service startup
- effective only upon AAI-internal-clients startup
- distributed via source-code repository to ONAP-project-clients
- XSD files and generated POJOs
- multiple OXM files and multiple EdgeRule files
- effective only upon ONAP-project-clients startup
|
| I release and beyond | AAI Schema is: - federation of AAI instances with disjoint/partially-overlapping schemas and databases
- facade to stitch disjoint schema and data back into a unified representation
- schema change and version upgrade by deploying new AAI instance to join federation
- rolling upgrade and data migration between AAI instances within federation
- support for multiple-sources-of-truth scenario:
AAI-1343
-
Getting issue details...
STATUS
- multiple-data-file configuration
- distributed as data files via deployment tools to AAI-internal-clients, i.e. multiple IDL files or multiple TOSCA files and CSAR files, without change to JAR files
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to AAI Schema Service, i.e. multiple IDL files or multiple TOSCA files and CSAR files
- effective upon AAI Schema Service run-time refresh
- distributed via run-time SDC API to AAI Schema Service, i.e. multiple TOSCA files and CSAR files
- effective upon AAI Schema Service run-time refresh
- distributed via run-time API to AAI-internal-clients
- effective upon AAI-internal-clients run-time refresh
- distributed as data files via deployment tools to ONAP-project-clients without change to JAR files
- effective upon ONAP-project-clients run-time refresh
- distributed via run-time API to ONAP-project-clients
- effective upon ONAP-project-clients run-time refresh
| - single-data-file configuration per version
- distributed via source-code repository to AAI-internal-clients
- built into and deployed as microservice JAR file
- effective only upon AAI Schema Service startup
- effective only upon AAI-internal-clients startup
- distributed via source-code repository to ONAP-project-clients
- XSD files and generated POJOs
- multiple OXM files and multiple EdgeRule files
- effective only upon ONAP-project-clients startup
- single unified AAI schema and database
|
| J release and beyond | |
|