ONAPARC-585 - Getting issue details... STATUS
Brief Project Overview (brief as it should be known)
At present, the service design need to be repeated for each VNF / test vendor, resulting in duplication and test complexity.
To achieve a more flexible NFV automated test platform, ONAP-based NFV automatic testing platform provides a quick test service(topology) design composed of tested VNF and test environment, as well as supports the import and reuse test service(topology) between different test environments.
New component capabilities for Guilin, i.e. the functional enhancements, if applicable
- Enhance SDC to support:
- Quickly design a test service (topology) composed with tested VNF and test environment (One way is to define abstract testing service (topology) template for each type of VNF);
- For the service designed, can be imported into SDC for modification or enhancement, or the test template can be reused for different test environments (the SDC needs to support service import).
New or modified interfaces
1. Import service CSAR package to generate a new service:
POST /v1/catalog/services/importService
2. Return whether the service is a abstract service:
GET /v1/catalog/abstract/service/serviceUUID/{uuid}/status
3. Copy a new service based on the existing service:
POST /v1/catalog/abstract/service/copy
4. Replace the abstract vnf in the abstract service template with the actual vnf:
PUT /v1/catalog/abstract/service/replaceVNF
If they are modified, are they backwards compatible?
Interface naming (point to an example)
Consumed API from other projects
Project | API Dependency | Notes |
|---|---|---|
Published API
Project | API | Notes |
|---|---|---|
Reference to the interfaces.
(Reference to the the swagger.json file(s) whenever possible)
What are the system limits?
.
Involved use cases, architectural capabilities or functional requirements.
Test Automation
Listing of new or impacted models used by the project (for information only).
(list all the relevant Jira tickets)