...

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:

DCAE (evidenced by https://gerrit.onap.org/r/#/c/73148/ change for rest-services/aai-client component)
APPC and CCSK (evidenced by
Jira Legacy
server System Jira
serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
key CCSDK-740
/
Jira Legacy
server System Jira
serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
key CCSDK-741
bug for named-query and XSD schema of response data)
VID (evidenced by https://lists.onap.org/g/onap-discuss/topic/openlab_vid_beijing_how/28275492 query for SDC models by distribution status)
- but also VID is removing some AAI model POJOs
  Jira Legacy
  server System Jira
  serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
  key VID-361
  but not all POJOs https://gerrit.onap.org/r/gitweb?p=vid.git;a=tree;f=vid-app-common/src/main/java/org/onap/vid/aai
POMBA (sub-project of Logging) uses AAI-Validation, which uses schema-ingest
Jira Legacy
server System Jira
serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
key AAI-2295

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 are 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

Jira Legacy

server	System Jira
serverId	4733707d-2057-3a0f-ae5e-4fd8aff50176
key	VFC-1193

/

Jira Legacy

server	System Jira
serverId	4733707d-2057-3a0f-ae5e-4fd8aff50176
key	OPTFRA-268

/

Jira Legacy

server	System Jira
serverId	4733707d-2057-3a0f-ae5e-4fd8aff50176
key	OPTFRA-291

, there is an OOF-to-VFC pairing for this scenario:

VFC component sources the "flavor name" from OOF component
Then VFC searches AAI using "flavor name" to find the corresponding "flavor id"
Finally "flavor id" is used to create a VM
See also discussion at https://lists.onap.org/g/onap-oof/topic/critical_issue_found_in/28277232

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)

See examples in AAI Schema Producer-Consumer Pairings

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

...

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.

Needing to deal with schema change fragility (see JIRA for "UnrecognizedPropertyException" or "Unrecognized field" error messages)

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:
  Jira Legacy
  server System Jira
  serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
  key AAI-1343
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

???

...

Versions Compared

Old Version 25

New Version Current

Key

Use Case Outlines

Page Comparison

Versions Compared

Old Version 25

New Version Current

Key

Use Case Outlines