VF-C requirements collection for Casablanca release
- Yan Yang
- maopeng zhang
- victor gao
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) | High | VF-C |
|
NF1.2 | S3P-scalability | single site horizontal scaling plan to split all DBs from VF-C existing components into one single DB components this task can be separated into the following sub tasks: 1) Add CI jobs for DB component 2) Add Dockerfile and docker build scripts for DB component 3) Add oom scripts for DB component 4) Add heat scripts for DB component 5) Remove DB server from nfvo-lcm 6) Remove DB server from nfvo-catalog 7) Remove DB server from gvnfm-vnflcm 8) Remove DB server from gvnfm-vnfres 9) Remove DB server from gvnfm-vnfmgr | High | VF-C | ZTE |
NF1.3 | S3P- Manageability | All application logging to adhere to ONAP Application Logging Specification v1.2 | High |
|
|
NF1.4 | S3P- Usablity | All existing APIs must be documented in Swagger 2.0 All new API’s must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines https://wiki.onap.org/display/DW/ONAP+API+Common+Versioning+Strategy+%28CVS%29+Proposal | High | VF-C | ZTE |
NF2 | Architecture Alignment | API improvement All APIs between internal components & external APIs should be generated by Swagger | medium | VF-C | ZTE |
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. | High | VF-C/OOF/Multicloud | Intel ZTE |
F3 | Scaling | Auto scaling | Low | DCAE/Holmes/Policy/VF-C |
|
UC1 | vCPE | VF-C integrates with opensource CPE VNFs via GVNFM in C Release | High | VF-C | ZTE |
UC2 | vVoLTE | VF-C integrates with SVNFM in C Release | High | ZTE | |
O1 | Integrate with OOF | Integrate with OOF to get VNF homing allocation | High | Intel ZTE | |
O2 | ETSI SOL alignment | Align VF-C northbound API with SOL005? and align VNFM driver Northbound APIs with SOL003 | Medium | SOL003: component owner Verizon? ZTE | |
O3 | Align R3 DM | Align R3 Tosca data model | Medium | ZTE | |
O4 | vimProxy | Improve vimProxy functionality | High | Huawei | |
O5 | Jira-945 Support multiple VNFM instances | Problem statement: The SVNFM driver can not list all possible VNFM instances using the VF-C NSLCM API, because the API only allows to query VNFM information based on the UUID of the VNFM. The driver must know the UUID of the managed VNFMs to be able to query the VNFM information from VF-C LCM API. Even if the UUID of the VNFM is passed during a LCM operation (ex. scale) from VF-C to SVNFM driver. The possible VNFM instances must be know by the driver even if there is no API call executed from VF-C to driver, since the VNFM driver may want to subscribe to ETSI LCN as part of the driver startup. Use case: Manage multiple VNFM instances from a single ONAP instance. Proposed solution: Add a new API to VF-C LCM that allows to query the list of the VNFM instances. | Medium | VF-C | Nokia |
O6 | Jira-946 Separate configuration parameters of runtime from design time | Problem statement: The VNF package (CSAR file) currently holds a section that contains runtime information (concrete image names, availability zones, IPs, ...). This section should be only specified at the point when the VNF / NS / E2E service is created via use-case UI / VID. The current VNF package hold environment specific values resulting in that it can only be deployed in one specific environment. Currently VF-C NSLCM API allows to specify additional data for a VNF and NS, but this section is never filled out by SO/usecase UI. Use case: The single VNF package can be deployed into different cloud environment (ex. difference availability zone) without modification. Proposed solution: Extend the use case UI to be able to specify key value pairs for each VNF and NS. The VNF / NS operator could specify the value for these as part of the NS creation. These values would be passed from use case UI to SO and then to VF-C NSLCM API. | Low | Modeling subcommittee /SDC/SO/UUI/VF-C Victor: it would be more consistent that we start this topic(runtime model) from modeling part, so that we could have the clear operation definition across the community | |
O7 | Jira-947 Support custom operation | Problem statement: Operations that is not covered by the current ETSI specifications / VF-C LCM implementation can not be triggered from the use case UI / VF-C LCM API. Use case: Trigger a VNF upgrade operation from the use case UI. Proposed solution:
| Low | UUI/SO/VF-C/Modeling Subcommittee Victor: It would be more consistent that we start this topic(Operation definition) from modeling part, so that we could have the clear operation definition across the community | |
O8 | Jira-948 Multi tenancy support | Problem description: The cloud connection in A&AI is located under /cloud-infrastructure/cloud-regions/cloud-region/{cloud-owner}/{cloud-region-id}. This may hold multiple esr-system-info elements. Each esr-system-info collection of many attributes including URL, username, password and default-tenant. To establish a connection with OpenStack the URL, username, password and default-tenant fields are required. VF-C NSLCM identifies a cloud by a vimId field which is a composition of {cloud-owner}/_{cloud-region-id}. This two fields does not select the cloud credentials, since an cloud region may have multiple esr-system-info entries. Use case: Deploy two VNF on different tenants on the same cloud. Proposed solution: Change the vimId on VF-C API to be constructed from the {cloud-owner}/{cloud-region-id}{tenantId} tuple making the cloud credential selection unique. | Medium | Need to discuss with bin Yang: Bin Yang: Taking openstack as an example, because cloud-region-id is aligned with the cloud-region-id of OpenStack. The default value is RegionOne in openstack. Supporting multiple tenants can be achieved by manually specifying different cloudowner in ESR GUI. | |
O9 | Jira-949 Support VNFMs with multiple end points | Problem description: A VNFM in ETSI have different endpoints (IP address) for different purpose. A couple of examples for endpoints are: authentication, LCM or LCN. The VNFM in A&AI is located under /external-system/esr-vnfm-list/esr-vnfm/ {vnfm-id} . The VNFM in A&AI may have multiple esr-system-info entries. Each entry may have many attributes (username, password, URL). VF-C only exposes the first element from the esr-system-info list. Use case: Register a VNFM with multiple API end points. Proposed solution: Change the ESR UI to be able to register multiple end points. Change the VNFM query API of VF-C LCM to return the full collection of end points instead of the first element. | Medium |
| Nokia |