...
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) |
R4 VF-C Security/Vulnerability - Full Content The following repos still have security issue java projects: 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 |
Security communication:
security Issue:
Components owner
vfc/nfvo/driver/vnfm/svnfm/huawei: Huawei
vfc/nfvo/driver/vnfm/gvnfm: Huawei
python projects: vfc-gvnfm-vnflcm vfc-gvnfm-vnfmgr vfc-gvnfm-vnfres |
vfc-nfvo- |
catalog vfc-nfvo-driver- |
vnfm-gvnfm vfc-nfvo-driver-vnfm-svnfm |
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
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
-zte vfc-nfvo-lcm | High | VF-C | Security communication:
|
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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 vfc-gvnfm-vnflcm vfc-gvnfm-vnfmgr vfc-gvnfm-vnfres vfc-nfvo-catalog vfc-nfvo-driver-vnfm-gvnfm vfc-nfvo-driver-vnfm-svnfm-zte vfc-nfvo-lcm For python components, chose one component to upgrade and test ,and then update the remaining components ZTE |
| NF1.3 | Remaining issue during Integration Testing-configuration | Investigate all VF-C configuration can be automatically injected through oom. 1.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. |
CMCC
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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
2. MSB registeration flag The Service will register to MSB automatically by code when service start , and when pod start, the service will also register to MSB via OOM. Need to consider how to deal with the duplicate service endpoint | High | VF-C, |
| OOM | CMCC
|
MSB Issue need find effective solution | ||
NF1. |
4 | Including VF-C to daily building testing | Investigate how to add VF-C to the daily building test case |
if we can leverage the CLI work | High | VF-C, Integartion, CLI |
|
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
Intel | |||||||||||||||
| NF1.5 | Start up way: uwsgi and runserver | During the integration testing, found some issue when use uwsgi to start the service. If add the enable-thread, the new thread can start up in component, but when the pod start, we encounter the empty reply from service | High | VF-C | During vCPE testing, we will query the unstable reason Intel, ZTE, 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
| NF1.6 | DB unstable | During the integration testing, found the DB connection will be lost during some DB operation. Need stable testing | High | VF-C | During vCPE testing, we will query the unstable reason Intel, ZTE, |
CMCC
|
CMCC/ZTE/Intel/Verizon
UC2
CCVPN
|
F3
Scaling
Auto scaling
F4
UC1
vCPE
VF-C integrates with opensource CPE VNFs via GVNFM in C Release
| NF1.7 | upgrade from python2 to python3 | Python 2.7 will reach the end of its life on January 1st, 2020 and won't be maintained after that date. A future version of pip will drop support for Python 2.7. | Medium | VF-C | chose one component, such as gvnfmdriver to update and test, then if we have time and resource in E release, we can update the remaining components ZTE |
|
| ||
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
Subscribe /Notify/ Query / Terminate - NSD Package
NSD
PNFD
Subscribe / Notify / Query / Terminate / Fetch - VNF PackageHeal VNF
Operation VNF
Scale VNF
LCM Notification
need use case to verify this | The NSLCM interface have aligned with SOL005 need use case to do the integration testing, especially for SO and VF-C integration | High | VF-C, SO, UUI |
Create NS API : ZTE
Delete NS API: ZTE
Get NS API :ZTE
Instantiate NS API: ZTE
Scale NS API： CMCC
Heal NS API: CMCC
Update NS API : CMCC
Terminate NS API :ZTE
Delete NS API :ZTE
NS LCM Operation Occurrences
NSD
PNFD
VNF Package Management APIs : Verizon
NSD Package Management APIs : Verizon
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
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
need confirm the test plan with SO and verizon guys . SO team confirmed that as ElAlto is more like a maintenance release they wouldn't push the SOL005 SO code in E release. So the SOL005 SO code will be part of Frankfurt release | |||||
O6 | OVP MVP | In OVP MVP， have added tosca validation ， VF-C will cooperate with OVP to provide the tosca-based VNF validation. | High | VF-C, VNFSDK, Integration, CLI | We suggest to leverage the VF-C existing feature , not to add new function Intel, Huawei, ZTE, CMCC VNFSDK will invoke VF-C NS APIs, when a VNF onboarding to SDC, CLI will invoke SDC internal API to design VNF to a NS, we need to make sure the NS can be associated with VNF under artifact directory. |
|
|
Align R4 DM
| Jira | ||||||||
|---|---|---|---|---|---|---|---|---|
|
O7 | Code refactoring | code style refactor, including good variable, function name,... etc const refactor test case refactor | middle | VF-C | ZTE
|
|
O5
VF-C workflow Optimization
The build-in workflow is executed by default in current VF-C code. In Dublin release, plan to perform different workflow branches through flexible configuration. At least, support activity workflow and build-in workflow at D release.
The main work include:
a. Activity workflow edit and writing
b. Activity workflow integration testing
| O8 | GVNFM Driver as SOL003 adapter | We would like to optimize GVNFM driver to make it can integrate with multiple SOL003 VNFM. Need to see whether it can support now or need to do some enhancement | middle | VF-C | xx |
|
O6
O7
| |||||
| O9 |