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. A&AI is critical to ONAP as 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)
- - 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 updates from various Clients, to persist & maintain a global view.
  - As transactions occur, AAI persists asset attributes and relationships into the view based on configurable metadata definitions.
  - Provides 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.
  - 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:

Service/Capability	Description
Model Loader	Pulls in models from SDC topic queue and loads them to AAI inventory.
Resources	CRUD REST API endpoints for AAI inventory resources
Traversal	REST APIs for graph traversals. Some APIs use the Gremlin Server.
UI	used by operations for visualizing and searching. Available through ONAP Portal.
Data Router:	Makes decisions about workloads to be dispatched to database abstraction services (including the search service). Includes logic to recognize and direct requests based on request archetypes.
Search:	Enable complex searches for sub graphs and functions that need to perform well across deeply nested structures using Elastic Search. Used by UI.
Champ	Abstraction from underlying graph storage systems that A&AI would interface with.
Gizmo	CRUD REST API endpoints for resources and relationships, delivering atomic interactions for improved scalability

Move to Active Open Source Graph Database (R1 candidate)
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.
SO has this UC also.
Variety of different options here (VIM/SO/Controller) - all valid.

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
- TitanDB
- Hbase
- AJSC
- EELF
- DMAAP
Integration Testing

Resources:

Primary Contact Person - Manisha Aggarwal (ma9181@att.com), Colin Burns (Colin Burns@amdocs.com)

Table of Committers:

Name	Gerrit ID	Company	Email	Time Zone
Manisha Aggarwal		AT&T	ma9181@att.com	Middletown, NJ, USA, UTC -4
Jimmy Forsyth		AT&T	jf2512@att.com	Michigan, USA, UTC -4
Steven Blimkie	sblimkie	Amdocs	Steven.Blimkie@amdocs.com	Ottawa, Canada, UTC -4
Tian Lee	TianL	Amdocs	tian.lee@amdocs.com	Bath, UK, UTC +1
Heliu Zhong		BOCO	zhongheliu@boco.com.cn	Beijing, China. UTC +8
Yuanwei Yang		BOCO	yangyuanwei@boco.com.cn	Beijing, China. UTC +8

Table of Contributors:

(Names and affiliations of any other contributors)

Name	Gerrit ID	Company	Email	Time Zone
Jimmy Forsyth		AT&T	jf2512@att.com	Michigan, USA, UTC -4
Ming Li		ZTE	li.ming23@zte.com.cn	Beijing, China. UTC +8
Fanhu Fu		ZTE	fu.fanhu1@zte.com.cn	Beijing, China. UTC +8
CT Paterson		Amdocs	Creighton.Paterson@amdocs.com	Ottawa, Canada, UTC -4
Colin Burns		Amdocs	colin.burns@amdocs.com	Bath, UK, UTC +1
Andrew Baxter		Amdocs	andrew.baxter@amdocs.com @amdocs.com	Bath, UK, UTC +1
Murali		Huawei	murali.p@huawei.com	Bangalore, India UTC +5:30
Jason Plurad		IBM	pluradj@us.ibm.com	Durham, NC, USA UTC -4Tuesday, May 30, 1500 UTC
Steve Blimkie	sblimkie	Amdocs	Steven.Blimkie@amdocs.com	Ottawa, Canada, UTC -4
Tian Lee	TianL	Amdocs	tian.lee@amdocs.com	Bath, UK, UTC +1
Michael Arrastia		Amdocs	marrasti@amdocs.com	Bath, UK, UTC +1
Gino Fraboni		Amdocs	gino.fraboni@amdocs.com	Ottawa, Canada, UTC -4
Arul Nambi		Amdocs	arul.nambi@amdocs.com	Ottawa, Canada, UTC -4
Harish Kajur		AT&T	vk250x@att.com	Middletown, NJ, USA, UTC -4
Robby Maharajh		AT&T	rx2202@att.com	Middletown, NJ, USA, UTC -4
Andrew Muller		AT&T	am8383@att.com	Middletown, NJ, USA, UTC -4
William Lamont		AT&T	wl2432@att.com	Middletown, NJ, USA, UTC -4
Giulio Graziani		Amdocs	giulio.graziani@amdocs.com	Ottawa, Canada, UTC -4
Dileep Ranganathan	dileep.ranganathan	Intel	dileep.ranganathan@intel.com	Santa Clara, CA, USA, UTC -7

Project Roles (include RACI chart, if applicable)

Other Information:

link to seed code (if applicable)
- gerrit.onap.org/r/a/aai/
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?
  The current seed code has been already scanned and cleanup to remove all proprietary trademarks, logos, etc. except openecomp to be replaced by onap
  Subsequent modification to the existing seed code should continue to follow the same scanning and clean up principles.
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), Steve Blimkie (Amdocs)

Project Name:

JIRA project name: Active and Available Inventory
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

TianL@amdocs.com

zhongheliu@boco.com.cn

yangyuanwei@boco.com.cn

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

Browser not supported