Requirements concerning M.C.
NF: Non-functional requirement
F: Functional requirement
UC: Use-case
O: Other requirements
ID | catalog | How MultiCloud is concerned |
NF1 | S3P | "All communication shall be able to be encrypted and have common rolebased access control and authorization. " |
NF2 | Security | "TLS for security of HTTP connections" |
NF3 | Architecture Alignment | K8S plugin |
NF4 | Architecture Alignment | Azure plugin |
F1 | Centralized Representation and Consistent ID of Cloud Regions | ONAP need centralized representation and consistent ID of cloud regions to enable multiple cloud/VIM orchestration, and multicloud is the consumer of the ID |
F2 | EA/Cloud Infrastructure for Distributed Edge Clouds | MultiCloud services deployed on edge cloud offers values such as near real-time latency and aggregating for less bandwidth consumption in case of close loop automation Primary use case – Multi Cloud to be deployed as part of ONAP Central (Edge Scoping MVP for Casablanca - ONAP Enhancements)
|
F3 | HPA | SRIOV |
F4 | HPA | HPA telemetry data collection and persistence. |
UC1 | vFW | Heat based orchestration, SO will leverage MutliVIM/Cloud for stack CRUD in C Release |
UC2 | vDNS | Heat based orchestration, SO will leverage MutliVIM/Cloud for stack CRUD in C Release |
O1 | Infrastructure upgrade | Integration Lab will be upgraded to Pike-based Titanium Cloud |
O2 | Infrastructure expansion | Orange lab is pike-based, new placement API available for HPA discovery |
O3 | Infrastructure expansion | Azure support - given Azure plugin is listed as NF4, is this needed? |
O4 | Infrastructure expansion | StaringX support |
Proposals:
Notes:
1,The proposals should correlate to Casablanca Release Requirements, hence feedback with effort/resource to implement it.
2, The prioritizing column is the suggestion from contributor's perspective, not necessarily be the priority of the whole Multi-VIM/Cloud project.
2, The proposals should be identified with the dependency of other ONAP projects or upstream projects.
Proposals for Casablanca | Correlation | Briefing | Dependency | Prioritizing | Effort level estimation | comments | Resource commitment |
Upgrade plugin for Wind River | O1 | Upgrade plugin for Wind River's new release of Titanium Cloud | Impacts: MC Titanium plugin Test on Integration Lab/Physical Lab Wind River Titanium Cloud R5 which is ready and will be deployed in Integration Lab | High | low | MVP | Wind River as MVP (Yun Huang) |
New plugin for Pike & Traits | F3, O2 | New plugin for Pike since pike based Titanium Cloud and pike based Orange Lab | Impacts: New MC OpenStack Pike Plugin Local test and Orange Lab OpenStack Pike which is ready and deployed in Orange Lab | High | medium | MVP | Intel as MVP(Haibin Huang) |
Consistent ID of cloud region enablement | F1, F2 | Support the functional requirement of "Centralized Representation and Consistent ID of a Cloud Region for ONAP" | Impacts: All MC plugins, include k8s/azure plugin VFC (MVP Yan, test on VoLTE case) OOF (MVP?) VID (Stretch goal) SDNC (Stretch goal) SO (Stretch goal) OOF (Stretch goal) APPC (Scaling case?) Pairwise testing with VFC and OOF. Consumers of MultiCloud agree on using the new ID format of Cloud Region. | High | Low to Medium | MVP | Wind River(Bin Yang) as MVP for OpenStack plugin, VMware (Ethan Lynn) as MVP for vio plugin, Azure plugin(Avi), k8s plugin(Victor) . |
Security enhancement: secured communication | NF2 | Enable secured endpoints for MultiCloud services, leverage service mesh for secured communication, encryption will happen on sidecar, so no change to multicloud plugins. Only apply to OOM deployment, won't support heat deployment since it's not release requirement. | Impacts: All MC plugins TSC decide to have this security feature for C. Release | Medium | low | MVP Ramki, Srini will share how service mesh help on this requirement. Bin: Just learned that service mesh can handle this with sidecar approach. TODO(Bin Yang): Check which project will deploy service mesh? OOM? MSB? | Wind River(Bin Yang) as a MVP, VMware(Ethan Lynn) as MVP |
Use OOF flavors(HPA) | F3 | Using flavors returned by OOF and pass them as parameters to HEAT command line, a new API between SO and MultiCloud, SO will only leverage this API to communicate with MultiCloud instead of using openstack/heat adapter. | Impacts: All MC plugins.(Evaluate the impacts to k8s/azure plugin) SO(Intel Marcus will contribute) OOF(Done in Beijing) Test with SO. SO leverages MultiCloud for heat based VNF orchestration | TBD | Medium | MVP? Ethan: SO might be more suitable to pass this parameter to MC. Bin: Yes, it is passed from SO. Ramki: Would be good to make it a library so that all openstack based plugin could use this library. How does other plugins(k8s/azure) leverage this API? Needs to discuss more about API design. | Intel(Haibin) for OpenStack Plugin, Wind River(Bin Yang) for Titanium plugin, VMware vio plugin(?), k8s/azure plugin(?). Bin Yang will continue discuss API design with SO and k8s/azure plugins. |
IaaS intent-based framework to support cloud agnostic intent for Compute/Network/Storage | F2 | Enhance MultiCloud check_vim_capacity API for homing policy, need to discuss what kind of cloud specific metrics need to handle in MultiCloud. | Impacts: MultiCloud cloud plugins (OS plugin/VIO plugin/Azure plugin) OOF(MVP Ramki will evaluate resources) A&AI(A&AT will contribute) Risk on testing it on integration lab. Might only be tested on VIO/Azure env. infrastructure modeling? | TBD | High | MVP for VIO/Azure plugin Stretch goal for Titanium/openstack/k8s plugin TODO(Ramki before Tuesday Morning PDT): 1. Give the exact resource so that we can assign to VIO development. 2. Get the confirmation from Microsoft(Azure) for development and testing. | Wind River(Bin Yang) for Titanium plugin as stretch goal. Amdocs(Avi) for azure plugin as MVP. VMware(Ramki) for vio plugin as MVP. Ramki will get additional resources. Intel(?) for k8s plugin as stretch goal. VMware(Ramki) for OpenStack Plugin as stretch goal? Intel, Amdocs (Microsoft) as MVP, VMware, Wind River (Bin Yang) as stretch goal |
Distributed Edge Cloud Infrastructure Capability Discovery adhering to the Infrastructure Modelling enhancements for Distributed Cloud | F2 | infrastructure modeling | TBD | Low | Stretch Goal offline discussion: dependency on infrastructure modeling | Intel, Amdocs (Microsoft) as MVP, VMware, Wind River (Bin Yang) as stretch goal | |
Deploy MultiCloud service to edge cloud with AAI in centralized ONAP | F2 | multicloud services deployed on edge clouds while AAI in central ONAP | Edge Cloud which is available for sure | low | low | Stretch goal | Wind River (Yun Huang) as a stretch goal |
HEAT orchestration enhancement | UC1, UC2 | Enable M.C. to update AAI inventory after heat orchestration/scaling/termination is done via M.C. plugin | SO will leverage MultiCloud for heat based VNF orchestration and require MultiCloud's help on updating AAI inventory | low | low | Ramki: it is critical that m.c. to play this role | Wind River(Bin Yang) as a stretch goal, others? |
Cloud Region decommission | F1 | With centralized cloud region realized, it is good to decommission the cloud region with a single click | N/A | low | low | Wind River (Yun Huang) as a stretch goal | |
Kubernetes plugin | NF3 | Create a MVP that allows to use Kubernetes as MultilCloud plugin | Low | High | Intel as a MVP (Victor MORALES), Wind River(Bin Yang) as a stretch goal | ||
Azure plugin | NF4 | TBD | High | Matti: Confirmed with Microsoft | Amdocs/Microsoft as MVP. | ||
StarlingX plugin | O4 | StarlingX release available | TBD | High | Intel (Haibin Huang) as MVP, Wind River (Bin Yang) as a stretch goal | ||
Security enhancement: RBAC enablement | NF2 | Role based access control | TSC decide to have this security feature for C. Release, but not pertain to specific implementation. | TBD | High | Bin: Up on security level from TSC decision. Bin: AAF python library is not available yet. Bin: Service Mesh/istio or MSB could be another option to realize that | Wind River(Bin Yang) as a stretch goal, but subject to TSC's decision |
SRIOV-NIC support | F3, F2 | HPA feature in OOF facilitates placing VDUs on the site that has compute nodes supporting needed SRIOV-NIC cards. Operators like to have flexibility of placing the workloads on non SRIOV-NIC machines in case there are no matching profiles. In HEAT templates, there is a challenge to have this kind of flexibility. | HPA end-to-end enablement w.r.t. SRIOV-NIC. AAI schema supports the inventory of SRIOV-NIC | TBD | High | Intel as MVP(Haibin Huang), Wind River(Bin Yang) as stretch goal, VMware as ? | |
Aggregated Infrastructure Telemetry Streams | F2 | collectd? | TBD | Medium | offline discussion: What is the intention/workflow | Intel as MVP, VMware to evaluate, Wind River to evaluate | |
HPA telemetry data collection and persistence | F4 | Collect and persist in AAI HPA telemetry data useful for instantiation and on-going operation of VNFs | High | Low/Med | Intel (Haibin Huang) as MVP |