Requirements concerning VF-C C release
NF: Non-functional requirement
F: Functional requirement
UC: Use-case
O: Other requirements
ID | catalog | How VF-C is concerned | priority | Projects Impacted | Resource commitment |
NF1.1 | S3P-security | CII Silver badge(Including no critical and high known vulnerabilities > 60 days old and other requirements),plus "All communication shall be able to be encrypted and have common rolebased access control and authorization. "( not committed) /wiki/spaces/SV/pages/16089212 The following repos still have security issue vfc/nfvo/driver/vnfm/svnfm/huawei vfc/nfvo/driver/vnfm/gvnfm vfc-nfvo-multivimproxy vfc-nfvo-resmanagement vfc-nfvo-driver-ems vfc-nfvo-driver-svnfm-nokiav2 | High | VF-C | Security communication: security Issue: Components owner vfc/nfvo/driver/vnfm/svnfm/huawei: Huawei vfc/nfvo/driver/vnfm/gvnfm: Huawei vfc-nfvo-multivimproxy: Huawei vfc-nfvo-resmanagement :Huawei vfc-nfvo-driver-ems : Boco vfc-nfvo-driver-svnfm-nokiav2 : nokia |
| NF1.2 | S3P-scalability | For DB components, would like to see how to meet S3P through OOM. Know from OOM team that MariaDB Galera Cluster can be used to meet S3P HA requirements. For other components, we should to do some test to see whether the components can work properly based on OOM replicas | High | VF-C, OOM | |
| NF1.3 | Remaining issue during Integration Testing-configuration | Investigate all VF-C configuration can be automatically injected through oom. During the integration testing, such as SDC URL and user/pwd should be updated manually to Catalog configuration, Before that, need to turn off the livenessprobe of k8s. | High | VF-C, OOM | |
| NF1.4 | Documentation | Improve VF-C documentation and make the user/developer to more easy to try to use VF-C https://onap.readthedocs.io/en/latest/submodules/vfc/nfvo/lcm.git/docs/platform/installation.html | High | VF-C, Doc | CMCC |
NF1.5 | Including VF-C to daily building testing | Investigate how to add VF-C to the daily building test case Need work with Integration team to do this | High | VF-C, Integartion | |
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 | High | MultiCloud/VF-C | CMCC |
F2 | HPA | Changes to VF-C will be required in order to incorporate use of HPA into instantiation and related operation. Although VF-C have integrated with OOF , but haven't used the VIM decision which got from OOF, still using the VIM passed by UUI | High | VF-C/OOF/Multicloud | Intel / ZTE /CMCC |
F3 | Scaling | Auto scaling | Low | DCAE/Holmes/Policy/VF-C | |
F4 | |||||
UC1 | vCPE | VF-C integrates with opensource CPE VNFs via GVNFM in C Release | High | VF-C | |
UC2 | |||||
O1 | SOL005 interface alignment | VF-C Northbound interfaces align with SOL005 Create NS API Delete NS API Get NS API Instantiate NS API Scale NS API Heal NS API Update NS API Terminate NS API Delete NS API NS LCM Operation Occurrences Subscription/Notify NSD PNFD VNF Package Management API | High | VF-C, SO, UUI | Create NS API : ZTE Delete NS API: ZTE Get NS API :ZTE Instantiate NS API: ZTE Scale NS API Heal NS API Update NS API Terminate NS API :ZTE Delete NS API :ZTE NS LCM Operation Occurrences Subscription/Notify NSD PNFD VNF Package Management API |
O2 | SOL003 interface alignment | The interface have been supported now : Create VNF Identifier Query VNF Query Multiple VNFs Delete VNF Identifier Instantiate VNF Terminate VNF Notify about VNF lifecycle endpoint Heal VNF only support restart one vm Operate VNF haven't been tested GET VNF LCM Operation occurrences Individual VNF LCM operation occurrence Subscribe to VNF lifecycle change notification Interface that will continue to implement are as follows : Heal VNF Operation VNF Scale VNF LCM Notification | High | VF-C | |
| O3 | Align R4 DM | Align R4 Tosca data model | Medium | ||
| O4 | |||||
O5 | |||||
O6 | |||||
O7 | |||||
| O8 | |||||
| O9 |