Page History

...

• Inventory for services and resources (core capability to be delivered in R1)

  • • Problem being addressed: Service and Resource information is critical to operational processes throughout the life cycle. When information is needed it should be made available quickly, accurately, reliably without overly impacting components in the ecosystem. Information must be made immediately available for newly defined service and resources.  

    • Delivering a single point of reference for service and resource details 

    • a central registry to create a global view of inventory and network topology

    • receives Receives updates from various inventory masters distributed throughout the ONAP infrastructure, and persists just enough to maintain the Clients, to persist & maintain a 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 a set of 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. 

    • A&AI will capture, maintain, and expose the data required to support the 3 ONAP R1 use-cases
      
      
  • Deliverables:

• Move to Active Open Source Graph Database  (R1 candidate)

  • Problem being addressed: 
    • 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)

• Problem being addressed: 
  • AAI needs to dynamically operationalize new and updated models at run-time, with minimal downtime and no coding, so that ONAP is always on, and that latest service and resource models can be delivered by ONAP quickly, and without release boundary. 
• To do this, AAI must 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 artifact(s) (TOSCA assumed) for schema and for model
  • Translate the common model artifact(s) to AAI native artifact(s)
  • Ingest and operationalize the new models - making appropriate changes to data stores, APIs, configurations
  • Operationalization should include an internal 2 phase commit to ensure that relevant AAI services are successfully updated
  • Operationalization should include an external 2 phase commit across all relevant ONAP components to  ensure they are successfully updated.
  • Decomposing AAI model/schema  artefacts - today's OXM is a monolith, a more granular approach will better enable extensibility and support  logical subdivision of modls
• First priority is the aspects of this behavior required for the 3 ONAP R1 use-cases

• Track Change through Time (R2+ candidate) 
  • Problem being addressed:
    • Some assurance use-cases require investigation of the historical state of a service or resource (i.e. there was severe service degradation last Tuesday, what did the network/service look like then)
    • A&AI today delivers insight only into current service and resource.
  • Tracking the changes to Service and Resource inventory across time
  • Support for point in time service/resource detail, e.g. for assurance 
  • Updated API to support query of  time series data

• AAI Reconciliation from Network/Cloud. (dependencies on Multi VIM project- assume R2 earliest)

• Problem being addressed:
  • Information supplied by AAI needs to be accurate to minimize fallout in operational processes.
  • Maintaining an accurate view of the service/resource is made more challenging by Increased autonomy within the network 
  • AAI needs mechanisms to ensure tight alignment with network, without significant additional load to the controllers. etc.
• 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 SO has this UC also.
• Variety of different options here (VIM/SO/Controller) - all valid.

...

• Primary Contact Person - Manisha Aggarwal (ma9181@att.com), Colin Burns (Colin Burns@amdocs.com)
  Names,gerritIDs, and company affiliations of the committers - Manisha Aggarwal(AT&T), Jimmy Forsyth (AT&T) and Steve Blimkie(Amdocs)
  

Table of Committers:

Table of Contributors:

(Names and affiliations of any other contributors)

• Project Roles (include RACI chart, if applicable)

...

Project Name:

• JIRA project name:aai Active and Available Inventory
• JIRA project prefix: aaiAAI-

Repo name: Lifecycle State: Primary Contact: Project Lead: mailing list tag [Should match Jira Project Prefix] 

...

ma9181@att.com AT&T

jf2512@att.com AT&T

Steven.Blimkie@amdocsBlimkie@amdocs.com Amdocs Amdocs

tianTianL@amdocs.lee@amdocs.commichael

zhongheliu@boco.arrastia@amdocscom.comcngino

yangyuanwei@boco.fabroni@amdocs.comarul.nambi@amdocs.comcn

Link to TSC approval: 
Link to approval of additional submitters: 

...