...
This project targets a logically centralized reference point for service and resource details serving other ONAP components and non-ONAP systems to enable fulfillment, closed loop, reporting, and other operational use cases. The existing sources of truth do not provide a cross domain view and are not designed to serve this information to multiple clients.
Scope:
Inventory for services and resources (core capability to be delivered in R1)
a central registry to create a global view of inventory and network topology
receives updates from various inventory masters distributed throughout the ONAP infrastructure, and persists just enough to maintain the global view.
As transactions occur, AAI persists asset attributes and relationships into the federated view based on configurable metadata definitions for each activity that determine what is relevant to the AAI inventory.
Provides standard APIs to enable queries from various clients regarding inventory and topology. Queries can be supported for a specific asset or a collection of assets. The AAI global view of relationships is necessary for forming aggregate views of detailed inventory across the distributed master data sources.
- metadata-driven, new resources and services can be added quickly with Service Design and Creation (SDC) catalog definitions, using the AAI model loader
Move to
Active Open Source Graph Database (
R1 candidate)
- OpenECOMP AAI is today delivered on TitanDB in ONAP
- TitanDB has no active Open Source community. No community updates for over 1 year
- .
- ONAP AAI needs to move away from alignment to Titan There is risk in aligning AAI to TitanDB due to lack of support, maintenance and ongoing development.
- Main scope for this feature is technical evaluation, selection, implementation of open source graph database options.
- Janus good candidate (http://janusgraph.org/)
- Janus supports Tinkerpop Abstraction implemented today in AAI.
- Janus is an evolution of TitanDB (fork)
- For support of Active-Active, Cassandra back-end is needed (rather than HBASE)
Extend Model-driven AAI Use cases (R1 candidate)
- AAI needs to dynamically update its internal model, external API and behavior at run-time to respond to change to service and resource models, including schema changes.
- OpenECOMP AAI today delivers a model loader capability that ingests native A&A models and generates the API.
- This capability needs to be extended to support:
- Retrieve the common model artefact (TOSCA assumed)
- Move forward the AAI model-driven story, driven by 3 use-case requirements
- For Resource, service and schema change.
- Includes definition of (model-driven) API
- Model evolution - as updates are made to schema, make changes to existing instance data.
- Decomposing OXM into multiple OXM files to support:
- Extensibility of Schema
- Logical subdivision of modeling
-
- Track Change through Time (R2+ candidate)
- Tracking the Service, Resource changes across time
- Support for point in time service/resource detail, e.g. for assurance
Scalable, HA AAI (assumed covered by ONAP level project)
- Back end needs to be HA. Need to confirm, explore.
- Testing vs performance, throughput
- Scaling AAI
AAI Reconciliation from Network/Cloud. (dependences on Multi VIM project- assume R2 earliest)
- Need to refresh from VIM
- data integrity checks and reconciliation
- event based updates from VIM/SO/Controller
- Different VIMs have different levels of detail.
- MSO has this UC also.
- Variety of different options here (VIM/SO/Controller).
Related work
Scalable, HA AAI (assumed covered by ONAP level project - Project does not yet exist for this)
- Back end needs to be HA. Need to confirm, explore.
- Testing vs performance, throughput
- Scaling AAI
Extend Model-driven AAI Use cases (R1 candidate)
- Move forward the AAI model-driven story, driven by3 use-case requirements
- For Resource, service and schema change.
- Includes definition of (model-driven) API
- Model evolution
- Track Change through Time (R2+ candidate)
- Tracking the Service, Resource changes across time Support for point in time service/resource detail, e.g. for assurance
Distributed AAI (assumed covered by ONAP level project - Project does not yet exist for this)
- How does AAI serve local orchestrator, local DCAE across large geographical regions
- Resource data, interim data cant be centralized - too costly.
--
Describe the functionality to be provided by the project. Please provide the full intended scope of the project; not just what is intended for the project's first release.
...
- Primary Contact Person - Colin Burns colin.burns@amdocs.com, Steven Blimkie Steven.Blimkie@amdocs.com
- Names,gerritIDs, and company affiliations of the committers
Names and affiliations of any other contributors
Name Gerrit ID Company Email Ming Li Fanhu Fu fu.fanhu1@zte.com.cn - Project Roles (include RACI chart, if applicable)
...