Public cloud providers may not provide all their flavours in all of their regions.

The public cloud provider provides global API end points from which a user can manage their leased resources in any of the regions.

The physical data center has various compute flavours defined. These flavours may be universal across all the physical data centers, or may be local.

The provider may support various transport options for access to the cloud and for inter-region transport.

If regional availability zones are provided, they may be run by remote control planes (alternatively via the federated cloud control plane).

Physical data centers may be organized into regional availability zones.

If the physical data center isn't run by a remote control plane, it has a local control plane, or may be partitioned into several local control planes.

If Network Zone is defined, the Local Control Plane belongs to a Network Zone.

The Network Zone is created as part of the physical design of the data center. Only large data centers are likely to have more than one Network Zone.

Like OpenStack, the local control plane may configure one or more local availability zones. These help with placement requirements.

A Compute Node is made a member of a local control plane.

The compute node is made into a member of a local availability zone.

The Resource Profile describes the physical hardware and hypervisor of the compute node.

If a federated cloud was certain to exist in all owner-operated clouds, we'd make the association with that, but we're only guaranteed the existence of physical data centers.

If a federated cloud was certain to exist in all owner-operated clouds, we'd make the association with that, but we're only guaranteed the existence of physical data centers.

If a federated cloud was certain to exist in all owner-operated clouds, we'd make the association with that, but we're only guaranteed the existence of physical data centers.

If a federated cloud was certain to exist in all owner-operated clouds, we'd make the association with that, but we're only guaranteed the existence of physical data centers.

This relationship is part of the physical design of the data center.

This relationship is part of the physical design of the data center. REMINDER: This is an information model, which identifies all the key entities, relations and attributes in the (cloud) Infrastructure domain. This is not a data model for implementation. The information elements for a public cloud. Should the model include the possibility of a network latency and jitter map, e.g., that could be instrumented by ONAP between the public cloud regions and availability zones that it plans to use? A&AI: complex A&AI: cloud-region A&AI: pserver XOR

PublicCloud Region is a public cloud provider's set of cloud data centers in a limited geography (e.g., a metropolitan area) and within a single jurisdictional boundary. The public cloud provider's name for the region. Example, Microsoft Azure has regions "East US" and "East US 2". The city, and/or state or province, and country where the PublicCloudRegion is.  Note that the public cloud providers typically at best provide a city name for where the PublicCloudRegion and its availability zones are located. E.g., Amazon AWS "US West" is in Northern California; "EU-West-2" is in London, "EU-West-3" is in Paris. E.g., Microsoft Azure "US Central" is in Iowa; "US East 2" is in Virginia; one has to search through non-Microsoft public records to find out that "US East 2" may be in Boydton, Virginia. A distinct location within a PublicCloudRegion that is insulated from failures in other Availability Zones, and provides inexpensive, low-latency network connectivity to other Availability Zones in the same region. VirtualComputeFlavour represents the virtual machine sizes made available by the cloud provider (called vmSize in Azure, Instance Type in AWS, Machine Type in Google Cloud). The name that the cloud provider uses for this flavour. E.g., Azure has a Standard_H8m with specifications like 8 vCPU, 112 GiB memory, 1000 GiB SSD ephemeral storage and a maximum of 2 NICs. Human readable description of the flavour. Number of virtual CPUs. (implicitly assumes a "standard" or normalized vCPU). Virtual memory size in some units (e.g., MB, GB, GiB). The maximum size, in some units, of the root disk allowed for this flavour. If not specified, it may default to the size of the software image used in constructing the virtual machine. Name-value pairs for additional information about the flavour, typically specific to a cloud-provider. Some examples include: swap disk size, maximum attachable disk count, maximum NICs, maximum cached throughput IOPs. Hardware Platform Awareness attributes available in this flavour. The variety of cloud orchestration. The ONAP instance has an account and credentials with the PublicCloudProvider. The ONAP instance has an Account and Credentials with the PublicCloudProvider. There may be various options for transport to the cloud and between regions in the cloud. The public cloud provider typically supports some virtualization file formats natively and provides translation utilities for other image formats. Software images and data disk images use these formats. The image formats include: - AMI - Amazon Machine Image - VHD/VHDX - Virtual Hard Disk - VMDK - ESX Virtual Machine Disk - Raw - QCOW2 - ISO - Docker container format List of native virtualization file formats supported by the cloudtype. The set of virtualization file formats for which the cloud provider makes translation-support available. Types of storage provided by the cloud provider. The networking capabilities afforded by the cloud, e.g., are packet-forwarding VNFs allowed? e.g., is Ethernet VPN supported?, etc. Typically anti-IP-spoofing blocks packet forwarding, and in some clouds it may not be permitted/possible to turn this off. The cloud provider (owner) may provide a federated view of the cloud data centers, e.g., provide global API endpoints. To facilitate operation in the cloud, identity, authentication and authorization should be federated. The variety of cloud orchestration. The ONAP instance has an account and credentials with the PublicCloudProvider. The ONAP instance has an Account and Credentials with the PublicCloudProvider. The cloud may have a control plane that is remote - i.e., apart from agents, not co-located with the physical data center. This opens the possibility of a single remote control plane managing several physical data centers. The control plane for the data center may be local rather than remote. The data center itself may be divided up among more than one local control plane. The physical data center in the owner operated cloud is at precisely known coordinates, unlike the public cloud region. The physical data center can range from a large installation to a rack of servers in a road-side cabinet. Several edge physical data centers may be grouped together into a regional availability zone; e.g., these may be associated with a single instance of a remote control plane. The physical data center may be partitioned into local availability zones, one or more per local control plane. This is the physical compute server, or in OpenStack parlance, a host. These are visible in the OpenStack Compute API to users with the administrative role. They may be similarly be visible in other implementations of an Owner-Operated Cloud. Total, used and available vCPUs, memory, local storage; SR-IOV VFs? E.g., in OpenStack, this is visible in the Compute API to users with the administrative role, and similarly may be visible in other owner-operated cloud implementations. The compute node capacity measure can be rolled up to availability zone, or other levels of aggregation. A hardware and hypervisor profile for the Compute Node. This will include HPA attributes. A profile will typically apply to many Compute Nodes. Hardware Platform Awareness attributes available in this flavour. Network Zone reflects the organization of the network fabric and the WAN edges of the data center. Network Zone information goes beyond what e..g, OpenStack APIs expose to users with the administrative role; in fact, this information is not in OpenStack. One can think of implementations where this information is made available from the cloud to ONAP for the purpose of very precise placement. Data center rack. The list of cloud providers that the ONAP instance is configured to use, including any owner-operated (private) clouds. ONAP should provide a default list, that the ONAP operator can customize. Element representing an owner-operated cloud. The major variety of cloud orchestration. ONAP should have a default list that the ONAP operator can customizie. Microsoft Azure Amazon Web Services EC2 VMWare Integrated OpenStack