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:
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 | |
|
6 Comments
Keong Lim
Pavel Paroulek, James Forsyth, Manisha Aggarwal, Venkata Harish Kajur, William Reehil, CT Paterson, Steven Blimkie, Robby Maharajh, please review, comment and update as needed.
Keong Lim
Does the SDC modelling include the equivalent of EdgeRule metadata?
Update the AAI-internal-clients to list only the ones having schema-ingestor library as a dependency.
Add an item for an IDL-abstraction layer, replace OXM/EdgeRule files, probably targeted to a release before using TOSCA files as input
Keong Lim
Updated.
Keong Lim
Chesla Wechsler appreciate if you could review and comment on this page to see how well aligned it is with your Service Instance thoughts.
Chesla Wechsler
Two initial things: I really like how this page is laid out and presents an evolution path. I also read the whole thread on the schema service to understand more about it.
My use case seems like it would leverage the schema service, particularly in the "TOSCA files and CSARs" which you have for a later release (but see caveat below).
Being able to drive AAI from SDC has always been a goal of mine. CT Paterson and I are aligned that the best of all worlds would have been for ONAP to be a complete framework that interpreted the models and any models could be dropped in and the platform would just work. I think we're far away from that and I'm not sure when ONAP would get there, or even if there is mind share to be that general. That being said, I still believe that converting AAI from being defined as "the superset of all possible things SDC can design and the platform can instantiate" to AAI being driven by the individual models is where we should head. I see the platform as having a need, for the foreseeable future, for some global types around which the platform knows how to operate (CT Paterson is sighing now). Those global types get extended by specific models, and producers of data that fit the syntax and semantics (think AAI edges here) have to have a place to share the results for consumers (as well as for themselves if they need to reconstitute something at a later date).
I would want all platform components to have a shared knowledge, driven from the models, as to how to interact with AAI. If this schema service is consuming the models and using them to define the valid information that can be made available through AAI, in a way we know is going to be quite dynamic, then I'm all for it.
Caveat: I think the original intention of TOSCA files and CSARs may have been to construct TOSCA that matches the OXM of AAI into inventory types. I think that continues the "superset" approach. What I would want to see is what I portrayed in my slides, which is that each node type defined in a model becomes a vertex type in AAI which knows its inheritance hierarchy as well as its composition. The inheritance hierarchy permits queries based on abstraction.
Note: I believe AAI has at least some logic to say "if version 2 of this API included 2 fields and version 3 included 3, a client doing a PUT using the version 2 API cannot affect the new field added with version 3". It's possible logic like that may help the backwards compatibility issues identified on the call regarding the concern that some clients may migrate to the model-driven approach and others may not.
Keong Lim
Sharon Chisholm appreciate if you could review and comment on this page to see how well aligned it is with your visions of a future AAI.