You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 16 Next »

Project Name:

  • Proposed name for the project: Active and Available Inventory
  • Proposed name for the repository: aai

Project description:

Active and Available Inventory (AAI) is the ONAP subsystem that provides real-time views of Resources and Services and their relationships. AAI not only forms a registry of active, available, and assigned assets, it also maintains up-to-date views of the multidimensional relationships among these assets, including their relevance to different components of ONAP. 

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 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.
      • Decomposiing 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) 
    • 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. (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

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.

Architecture Alignment:


  • How does this project fit into the rest of the ONAP Architecture?
    • AAI is one of the key functional blocks in the ONAP Architecture
  • What other ONAP projects does this project depend on?
  • SDC / Modelling
  • Multi VIM / SO / SDN-C
  • CommServ1 /MSB
  • Integration
  • OpenLab
  • How does this align with external standards/specifications?
    • APIs/Interfaces - TinkerPop, Gremlin
    • Information/data models - ONAP TOSCA model
  • Are there dependencies with other open source projects?
    • APIs/Interfaces
      • Titan
      • Hbase 
      • AJSC
      • EELF
      • DMAAP
    • Integration Testing

Resources:

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


NameGerrit IDCompanyEmailTime Zone
Manisha AggarwalAT&Tma9181@att.comMiddletown, USA, UTC -4
Jimmy Forsyth
AT&Tjf2512@att.comMichigan, USA, UTC -4
Steven Blimkie
AmdocsSteven.Blimkie@amdocs.comOttawa, Canada


Other Information:

  • link to seed code (if applicable)
  • Vendor Neutral
    • if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
  • Meets Board policy (including IPR)

Use the above information to create a key project facts section on your project page

Key Project Facts

Primary Contact: Manisha Aggarwal (AT&T), Colin Burns (Amdocs)
Project Lead: Manisha Aggarwal (AT&T)

Project Name:

  • JIRA project name:aai
  • JIRA project prefix:aai

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

Committers: 

ma9181@att.com AT&T

jf2512@att.com AT&T

Steven.Blimkie@amdocs.com Amdocs

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


  • No labels