Versions Compared

Old Version 28

changes.mady.by.user Keong Lim

Saved on

compared with

New Version 29

changes.mady.by.user Keong Lim

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

...

ONAP Release TargetUse Case SummaryDeprecated 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 beyondEach 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 beyondEach 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 beyondEach 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 query)
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 beyondEach 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
      serverONAP JIRA
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keyAAI-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
  • ???