...

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 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.

...