Goal

ONAP has to be able to create and manage the life cycle of VNFs and services with operations automation in the context of multiple clouds, for example:

...

The data model should be structured to help and not hinder, to the extent possible for a data model, the architectural desired separation of concerns between ONAP and the clouds.

Challenge

That a useful-to-ONAP cloud-agnostic abstraction is possible can only be demonstrated by creating it. That being said, the key word here is "useful". This data model is not NOT intended to address every feature, capability, resource type and operation in every cloud. The focus is on "What does ONAP need?", and to specify the concepts needed for the ONAP view of a cloud infrastructure.

In particular, at a minimum:

1. The data model must provide a representation of the cloud resources identified in the VNF Descriptor model.
2. The data model must provide a representation of the information that the Service Orchestrator sends towards the cloud.
3. The data model must represent the information needed for the ONAP Optimization Framework.
4. The data model must enable mapping of relevant data of the specific cloud resources created by ONAP into the A&AI inventory.
5. The data model must facilitate the consumption of cloud-specific telemetry.
6. The data model must support distributed edge cloud DCs.

Scope

1. The initial scope is for virtual machine based workloads, but work on containers must also start.
2. OpenStack private and public clouds, and Azure as a public cloud are the minimum that the initial model must handle.
3. It is assumed, for the initial model, that VNFs use only the set of similar cloud resources listed here.

Principles

1. Generic: provides a description of any cloud
2. Simple: clear definition with examples
3. Adequate to address immediate use cases (e.g., Edge Automation)
4. Extensible – not intended to be final, complete, comprehensive
5. Standards-compliant (with proposed extensions to standard where necessary)

Methodology

1. The data model should be illustrated by examples, that tend to show that model expresses what it needs to.
   1. For example, demonstrate the mappings from the data needed by the APIs to the cloud infrastructure data model.
2. Align with ETSI NFV IFA 015 as much as is reasonable. Originality in data modeling is not a virtue.
3. Creating and maintaining modeled data is expensive. Only what is necessary should be modeled.

Proposals

1. Cloud Infrastructure Aggregate Representation Classes