...
- Proposed name for the project: Multi VIM/Cloud for Infrastructure Providers
- Proposed name for the repository: multicloud
Project description:
Motivation
- ONAP needs underlying virtualized infrastructure to deploy, run, and manage network services and VNFs.
- The service provider looks providers always look for flexibility in its choice of onand choice in selecting virtual and cloud infrastructure implementations, for example, on-premise private cloud, public cloud, or hybrid cloud implementations, and related network backends.
- ONAP needs to maintain platform backward compatibility with every new release.
Goal
- Multi-VIM/Cloud project This project aims to enable ONAP to support deploy and run on multiple infrastructure environments, for example, OpenStack and its different distributions (e.g. vanilla OpenStack, openstack.org, Wind River, etc...), public and private clouds (e.g. , VMware, Azure), and micro services containers, etc.
- Multi-VIM/Cloud project will provide a Cloud Mediation Layer supporting multiple infrastructures and network backends so as to effectively prevents vendor lock-in.
- Multi-VIM/Cloud project ONAP needs to maintain platform backward compatibility with every new release. This project decouples the evolution of ONAP platform from the evolution of underlying cloud infrastructure, and minimize minimizes the impact to on the deployed ONAP while upgrading the underlying cloud infrastructures independently.
- CDP-PAL ( Continuous Deployment Platform - Provider Abstraction Layer) is a thin, opaque API that surrounds the underlying cloud implementation, abstracting the implementation, providing a consistent and standard interface to access cloud infrastructure providers. CDP-PAL helps automate the creation, migration, and management of cloud-deployed applications and their needed hardware/software environment. PAL will be used in the common cloud architecture to allow for the deployment, migration, and scaling up/down of cloud deployed applications. CDP-PAL supports AWS, Azure, Baremetal, VMware and Openstack.
Scope:
Scope:
The scope of Multi-VIM/Cloud project is a plugable and extensible framework that
- provides a Multi-VIM/Cloud Mediation Layer which includes the following functional modules
- Provider Registry to register infrastructure site/location/region and their attributes and capabilities in A&AI
- Infra Resource to manage resource request (compute, storage and memory) from SO, DCAE, or other ONAP components, so as to get VM created and VNF instantiated at the right infrastructure
- SDN Overlay to configure overlay network via local SDN controllers for the corresponding cloud infrastructure
- VNF Resource LCM to perform VM lifecycle management as requested by VNFM (APP-C or VNF-C)
- FCAPS to report infrastructure resource metrics (utilization, availability, health, performance) to DCAE Collectors for Close Loop Remediation
- provides a A plugable and extensible framework thatprovides a Mediation Layer which includesA common northbound interface (NBI) / Multi-Cloud APIs of the functional modules to be consumed by SO, SDN-C, APP-C, VF-C, DCAE etc.
- provides a A common abstraction model
- The provides the ability to
- handle differences in models
- generates generate or extends extend NBI based on the functional model of underlying infrastructure
- allows Infrastructure Controller to register with capacity info & capabilities (for supporting EPA), discover and choose one or more VIM(s) to use
- allows global SDN Controller to choose and work with multiple local SDN Controller backends
- implements implement adapters for different providers.
Across the project, the implementation of any differentiated functionalities will be done in a way where ONAP users can decide if to use or not to use those functionalities.
...
Multi-VIM/Cloud project will align with the Common Controller Framework to enable reuse by different ONAP elements.
Deliverables of Release One:
Note: this section is for brainstorming and informational purpose, and subject to change during release planning stage
In R1, we target to support
- Maintain OpenStack APIs as the primary interface (Nova, Neutron, etc) to mitigate the risk and impact to other projects
- As of this date, we expect to support Vanilla OpenStack based on Ocata, and commercial OpenStack based on Mitaka (see below)
- Other OpenStack distributions in theory should work, but need other cloud providers to commit resources in the scope of R1 (Redhat, Mirantis, Canonical, etc)
- Provide support for 4 cloud providers and align with R1 use case
- Vanilla OpenStack, VMware Integrated OpenStack, Wind River Titanium Server, and Microsoft Azure (Azure to provide HEAT to ARM translator)
- Minimal goal: any single cloud provider from above across multi-sites (TIC edge and TIC core)
- including implementation of the adapters for above clouds
- Stretch goal: mix-match
- Minimal goal: any single cloud provider from above across multi-sites (TIC edge and TIC core)
- Vanilla OpenStack, VMware Integrated OpenStack, Wind River Titanium Server, and Microsoft Azure (Azure to provide HEAT to ARM translator)
- Minimal
- Implementation of the adapters for VMware, OpenStack (Wind River), and Microsoft Azure.
- Demo use case within a single site, supported by any single cloud provider.
- For vVoLTE or vCPE, enable single cloud provider across multi-site
- Stretch goal
- For vVoLTE or vCPE, enable mix
- of different cloud providers across multi-
- sites
- For vVoLTE or vCPE, enable mix
Architecture Alignment:
- How does this project fit into the rest of the ONAP Architecture?
The proposed Multi-VIM/Cloud layer will be added into the infrastructure controller. It has dependencies with SO, DCAE, A&AIMediation Layer consists of five functional modules, which interacts with SO, SDN-C, APP-C/VNF, VF-C, Modeling, and DCAE and A&AI respectively. It will act as the single access point to be called by these components for accessing the cloud and virtual infrastructure. Furthermore, it will align interact with SDN-C component to configure overlay network via local SDN controllers for both intra-DC connectivity as well as and inter-DC connectivity of the corresponding cloud infrastructure. Thus it is also the single access point for SDN-C to work with other local SDN Controllers. Applications/VNFs can be homed to the different cloud providers through the standard ONAP methods. For automated homing (SNIRO), different cloud providers can register attributes that differentiate their cloud platforms (e.g., reliability, latency, other capabilities) in A&AI and application placement policies/constraints can request for these specific properties (e.g., reliability > 0.999).
CDP-PAL is a multi-tenant online application, with access provided by a web interface. The user signs in to CDP-PAL to manage their "tenant" (similar to an account or a business organization within CDP-PAL which may have any number of users associated with it). A user can then create, edit, provision, etc a blueprint model, manage the created stacks (the instances that are created from the model), and administer the tenant and all of its resources.
Is there any overlap with other ONAP components or other Open Source projects?
There is no intentional or unintentional overlap with other ONAP components or other Open Source projects to the best of our knowledge
What other ONAP projects does this project depend on?
...
Consumers of Multi-VIM/Cloud – SO, SDN-C, APP-C
...
, VF-C, DCAE
...
Producers for Multi-VIM/Cloud – DCAE, A&AI\
Dependencies – Modeling
Alignment of Reusable APIs – Common Controller Framework
Indirect Impact and Collaboration – SNIRO, SDC
- How does this align with external standards/specifications?
- Support existed functions
- Information/data models by ONAP modeling project
- Compliant with ETSI NFV architecture framework
- VIM, NFVI, Nf-Vi, Vi-Vnfm, and Or-Vi
- Are there dependencies with other open source projects?
Cassandra, OpenStack java Java sdk, AWS Java sdk, Azure and Bare metal.
Resources:
- PTL
Bin Yang, biny993, bin.yang@windriver
- Danny Lin, lind@vmware
.com,
VMwareWind River
- Names, Gerrit IDs, emails, and company affiliations of the committers
Alon Strikovsky, alon.Strikovsky@amdocs.com, Amdocs- Anbing Zhang, zhanganbing@chinamobile.com, China MobileAndrew Philip, aphilip@microsoft.com, Microsoft
- Bin Hu, bh526r, bh526r@att.com, AT&T
- Bin Yang, biny993, bin.yang@windriver.com, Wind RiverKanagaraj Manickam (mkr1481), kanagaraj.manickam@huawei
- Ethan Lynn, ethanlynnl@vmware.com, HuaweiVMware
Xinhui Li,
xinhuili, lxinhui@vmware.com, VMware
- Jinhua Fu, fu.jinhua@zte.com.cn, ZTE
- Names and affiliations of any other contributors
Alex Vul, alex.vul@intel.com, Intel
- Alon Strikovsky, alon.Strikovsky@amdocs.com, Amdocs
- Anil Vishnoi, vishnoianil@gmail.com,
- Andrew Philip, aphilip@microsoft.com, Microsoft
- Arash Hekmat, arash.hekmat@amdocs.com, Amdocs
- Bin Sun, bins@vmware.com, VMware
- Claude Noshpitz cn5542@att.
- Claude Noshpitz claude.noshpitz@att.com, AT&T
- Dominic Lunanuova, dgl@research.att.com, AT&TEthan Lynn,
- ethanlynnl@vmwareGautam S, GAUTAMS@amdocs.com, VMwareAmdocs
- Gil Hellmann, gil.hellmann@windriver.com, Wind River
- Haibin Huang, haibin.haung@intel.com, Intel
- Hong Hui Xiao, honghui_xiao@yeah.net,
- Huang Zhuoyao, haunt.zhuoyao@zte.com.cn, ZTE
- Isaku Yanahata, isaku.yamahata@intel.com, Intel
- Jinhua Fu, fu.jinhua@zte.com.cn, ZTE
- John Murray, jm2932@att.com, AT&T
- Kanagaraj Manickam, mkr1481, kanagaraj.manickam@huawei.com, Huawei
- Liang Ke, lokyse@163.com,
- Madhu Nunna, mnunna@mirantis.com, Mirantis
- Manoj K Nair, manoj.k.nair@netcracker.com, NetCracker Technology
- Maopeng Zhang, zhang.maopeng1@zte.com.cn, ZTE
- Marcin Bednarz, mbednarz@mirantis.com, Mirantis
- Matti Hiltunen, hiltunen@att.com, AT&T
- Michael O'Brien, frank.obrien@amdocs.com, Amdocs
- Piyush Garg, piyush.garg1@amdocs.com, Amdocs
- Ram Koya, rk541m@att.com, AT&T
- Ramesh Tammana, ramesht@vmware.com, VMware
- Ramki Krishnan, ramkik@vmware.com, VMware
- Ramu N, rams.nsm@gmail.com,
- Robert Tao, roberttao@huawei.com, Huawei
- Sandeep Shah, ss00473517@techmahindra.com, Tech Mahindra
- Satish Addagadda, sa482b@att.com, AT&T
Shimon Seretensky shimon.seretensky@amdocs.com, Amdocs
- Srinivasa Addepalli, srinivasa.r.addepalli@intel.com, Intel
- Sumit Verdi, sverdi@vmware.com, VMware
- Tapan Majhi, Tapan.Majhi@amdocs.com, Amdocs
- Tom Tofigh, ttofigh@gmail.com,
- Tyler Smith, ts4124@att.com, AT&T
Varun Gudisena, vg411h@att.com, AT&T
Victor Gao, victor.gao@huawei.com, Huawei
Virginie Dotta, vdotta@fr.ibm.com, IBM
Yang Xu, yang.xu3@huawei.com, Huawei
- Project Roles (include RACI chart, if applicable)
...
Lifecycle State: incubation
Primary Contact: Danny Lin, VMware
Project Lead: To Be ElectedPTL: Bin Yang, Wind River
mailing list tag: multicloud
Committers:
- aphilip@microsoft.com
- bh526r@att.com
- bin.yang@windriver.comfu
- ethanlynnl@vmware.com
- lxinhui@vmwarejinhua@zte.com
- cn
Contributors
- kanagarajalex.manickam@huaweivul@intel.com
- lxinhui@vmwarealon.Strikovsky@amdocs.com
- zhanganbing@chinamobileAnton.Snitser@amdocs.com
- vg411h@attarash.hekmat@amdocs.com
...
- bins@vmware.com
- claude.noshpitz@att.com
- EyalH@Amdocs.com
- frank.obrien@amdocs.comdgl@research
- fu.attjinhua@zte.com.cn
- ethanlynnl@vmwaregautams@amdocs.com
- gil.hellmann@windriver.com
- haibin.haung@intel.com
- hiltunen@att.com
- haunt.zhuoyao@zte.com.cn
- honghui_xiao@yeah.net
- isaku.yamahata@intel.com
- jm2932@att.com
- kanagaraj.manickam@huawei.com
- lokyse@163.com
- ramesht@vmware.com
- ramkik@vmware.com
- rk541m@att.com
- sa482b@att.com
- Shimon.Seretensky@amdocs.com
- srinivasa.r.addepalli@intel.com
- sverdi@vmware.com
- tapan.majhi@amdocs.com
- ttofigh@gmail.com
- ts4124@att.com
- vg411h@att.com
- rams.nsm@gmail.com
- roberttao@huawei.com
- vdotta@fr.ibm.com
- victor.gao@huawei.com
- vishnoianil@gmail.com
- yang.xu3@huawei.com
- zhang.maopeng1@zte.com.cn
*Link to TSC approval:
Link to approval of additional submitters:
in selecting virtual and cloud infrastructure implementations