SOL005 issueshttps://forge.etsi.org/rep/nfv/SOL005/-/issues2024-02-01T08:47:32Zhttps://forge.etsi.org/rep/nfv/SOL005/-/issues/37MirroringInfo data type missing in SOL005 LCM definition version 4.4.12024-02-01T08:47:32ZPietro PiscioneMirroringInfo data type missing in SOL005 LCM definition version 4.4.1The MirroringInfo data type defined in the [ETSI GS NFV-SOL 005 V4.4.1 specification](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/005/04.04.01_60/gs_NFV-SOL005v040401p.pdf) at clause 6.5.3.106 is missing within the SOL005 LCM de...The MirroringInfo data type defined in the [ETSI GS NFV-SOL 005 V4.4.1 specification](https://www.etsi.org/deliver/etsi_gs/NFV-SOL/001_099/005/04.04.01_60/gs_NFV-SOL005v040401p.pdf) at clause 6.5.3.106 is missing within the SOL005 LCM definition version 4.4.1 version here: https://forge.etsi.org/rep/nfv/SOL005/-/blob/v4.4.1/src/SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml?ref_type=tagshttps://forge.etsi.org/rep/nfv/SOL005/-/issues/36PUT /vnf_packages/{vnfPkgId}/package_content; Incorrect schema of the request...2023-02-13T13:30:06ZbanerjeesuPUT /vnf_packages/{vnfPkgId}/package_content; Incorrect schema of the request “#/components/requestBodies/VnfPackageContentRequest”As per the SOL003 (4.3.1) Spec, the VnfPackageContentRequest has no fields / properties prescribed. However, in the swagger (yaml) declarations, the properties “file” is defined as application/binary:
```
VnfPackageContentRequest:
...As per the SOL003 (4.3.1) Spec, the VnfPackageContentRequest has no fields / properties prescribed. However, in the swagger (yaml) declarations, the properties “file” is defined as application/binary:
```
VnfPackageContentRequest:
content:
application/binary:
schema:
properties:
file:
type: file
description: |
The payload body contains a ZIP file that represents the VNF package. The "Content-Type" HTTP header shall
be set according to the type of the file, i.e. to "application/zip" for a VNF Package as defined in ETSI GS NFV-SOL 004.
format: binary
required: true
```
This causes the Open-Api Code generator for the Spring-boot to nest a JSON field “file” within a wrapper class: “VnfPackagesVnfPkgIdPackageContentGetRequest.java”
So, the Spring framework rejects the request as Unsupported Media Type “application/zip”. Supported Media Types: [“application/json”]
```
/**
* Class: VnfPackagesVnfPkgIdPackageContentGetRequest
*/
@JsonTypeName("_vnf_packages__vnfPkgId__package_content_get_request")
@Generated(value = "org.openapitools.codegen.languages.SpringCodegen", date = "2023-02-13T18:25:48.058910+05:30[Asia/Kolkata]")
public class VnfPackagesVnfPkgIdPackageContentGetRequest {
@JsonProperty("file")
private org.springframework.core.io.Resource file = null;
public VnfPackagesVnfPkgIdPackageContentGetRequest file(org.springframework.core.io.Resource file) {
this.file = file;
return this;
}
```
—--
> Fix required: The swagger SOL005/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml should NOT define a property “file”, given the request content in its entirety is a BINARY (and not a JSON/XML)https://forge.etsi.org/rep/nfv/SOL005/-/issues/35Missing `type: file` and relevant content-type/accept headers in some endpoin...2022-09-05T14:19:14ZkaidosMissing `type: file` and relevant content-type/accept headers in some endpoints in NSDManagement and VNFPackageManagementIn branch 2.8.1, 2.7.1-maintenance and possibly others, there are missing definitions on operations that accept or return files and relevant header restrictions. Here's two patches for the NSDManagement and VNFPackageManagement:
```diff...In branch 2.8.1, 2.7.1-maintenance and possibly others, there are missing definitions on operations that accept or return files and relevant header restrictions. Here's two patches for the NSDManagement and VNFPackageManagement:
```diff
diff --git a/src/SOL005/NSDManagement/NSDManagement.yaml b/src/SOL005/NSDManagement/NSDManagement.yaml
index f3dd8cc..eff8fd1 100644
--- a/src/SOL005/NSDManagement/NSDManagement.yaml
+++ b/src/SOL005/NSDManagement/NSDManagement.yaml
@@ -601,6 +601,8 @@ paths:
Content-Type:
description: The MIME type of the body of the response.
type: string
+ enum:
+ - application/zip
maximum: 1
minimum: 1
WWW-Authenticate:
@@ -617,6 +619,8 @@ paths:
type: string
maximum: 1
minimum: 1
+ schema:
+ type: file
206:
# description: >
# 206 PARTIAL CONTENT
@@ -702,6 +706,15 @@ paths:
type: string
enum:
- application/zip
+ - in: formData
+ name: file
+ required: false
+ type: file
+ description: >
+ The payload body contains a ZIP file that represents the NSD archive, as specified above.
+ The request shall set the "Content-Type" HTTP header to "application/zip"
+ consumes:
+ - multipart/form-data
responses:
202:
description: >
```
```diff
diff --git a/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml b/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml
index f53a644..f150517 100644
--- a/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml
+++ b/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml
@@ -540,6 +538,8 @@ paths:
Content-Type:
description: The MIME type of the body of the response.
type: string
+ enum:
+ - application/zip
maximum: 1
minimum: 1
WWW-Authenticate:
@@ -556,6 +556,8 @@ paths:
type: string
maximum: 1
minimum: 1
+ schema:
+ type: file
400:
$ref: "../responses/SOL005_resp.yaml#/responses/400"
401:
@@ -834,6 +832,9 @@ paths:
Content-Type:
description: The MIME type of the body of the response.
type: string
+ enum:
+ - text/plain
+ - application/zip
maximum: 1
minimum: 1
WWW-Authenticate:
@@ -850,6 +851,8 @@ paths:
type: string
maximum: 1
minimum: 1
+ schema:
+ type: file
400:
$ref: "../responses/SOL005_resp.yaml#/responses/400"
401:
@@ -941,6 +944,8 @@ paths:
Content-Type:
description: The MIME type of the body of the response.
type: string
+ enum:
+ - application/zip
maximum: 1
minimum: 1
WWW-Authenticate:
@@ -957,6 +962,8 @@ paths:
type: string
maximum: 1
minimum: 1
+ schema:
+ type: file
206:
$ref: "../responses/SOL005_resp.yaml#/responses/206"
409:
@@ -996,7 +1003,7 @@ paths:
consumes:
- multipart/form-data
parameters:
- - name: Accept
+ - name: Content-Type
description: >
Content-Types that are acceptable for the response.
in: header
@@ -1181,6 +1188,8 @@ paths:
Content-Type:
description: The MIME type of the body of the response.
type: string
+ enum:
+ - application/zip
maximum: 1
minimum: 1
WWW-Authenticate:
@@ -1197,6 +1206,8 @@ paths:
type: string
maximum: 1
minimum: 1
+ schema:
+ type: file
206:
description: >
206 Partial Content.
@@ -1220,6 +1231,8 @@ paths:
Content-Type:
description: The MIME type of the body of the response.
type: string
+ enum:
+ - application/zip
maximum: 1
minimum: 1
WWW-Authenticate:
@@ -1230,6 +1243,8 @@ paths:
has provided an invalid authorization token.
maximum: 1
minimum: 0
+ schema:
+ type: file
400:
$ref: "../responses/SOL005_resp.yaml#/responses/400"
401:
@@ -1460,6 +1475,8 @@ paths:
type: string
maximum: 1
minimum: 1
+ schema:
+ type: file
206:
description: >
Partial Content.
@@ -1497,6 +1514,8 @@ paths:
has provided an invalid authorization token.
maximum: 1
minimum: 0
+ schema:
+ type: file
400:
$ref: "../responses/SOL005_resp.yaml#/responses/400"
401:
```https://forge.etsi.org/rep/nfv/SOL005/-/issues/34Return schema in VNFPackageManagement shouldn't be nested in properties2022-09-05T13:26:38ZkaidosReturn schema in VNFPackageManagement shouldn't be nested in propertiesIn branches 2.8.1, 2.7.1-maintenance , 2.6.1-maintenance, the return schema in 3 operations is wrongfully nested compared to the spec. This:
```yaml
schema:
properties:
VnfPkgInfoModifications:
$ref: "definitions/SOL005VNFPa...In branches 2.8.1, 2.7.1-maintenance , 2.6.1-maintenance, the return schema in 3 operations is wrongfully nested compared to the spec. This:
```yaml
schema:
properties:
VnfPkgInfoModifications:
$ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfoModifications"
```
Should be like this:
```yaml
schema:
$ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfoModifications"
```
Here's a patch for it for branch 2.7.1-maintenance:
```diff
diff --git a/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml b/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml
index f53a644..69ab3a1 100644
--- a/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml
+++ b/src/SOL005/VNFPackageManagement/VNFPackageManagement.yaml
@@ -401,9 +401,7 @@ paths:
maximum: 1
minimum: 1
schema:
- properties:
- VnfPkgInfoModifications:
- $ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfoModifications"
+ $ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/VnfPkgInfoModifications"
400:
$ref: "../responses/SOL005_resp.yaml#/responses/400"
401:
@@ -648,9 +646,7 @@ paths:
maximum: 1
minimum: 1
schema:
- properties:
- ExternalArtifactsAccessConfig:
- $ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/ExternalArtifactsAccessConfig"
+ $ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/ExternalArtifactsAccessConfig"
416:
$ref: "../responses/SOL005_resp.yaml#/responses/416"
400:
@@ -731,9 +727,7 @@ paths:
maximum: 1
minimum: 1
schema:
- properties:
- ExternalArtifactsAccessConfig:
- $ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/ExternalArtifactsAccessConfig"
+ $ref: "definitions/SOL005VNFPackageManagement_def.yaml#/definitions/ExternalArtifactsAccessConfig"
202:
$ref: "../responses/SOL005_resp.yaml#/responses/202"
400:
```https://forge.etsi.org/rep/nfv/SOL005/-/issues/23Cannot specify default NS instantiation level of InstantiateVnfData data type2022-07-29T09:53:10ZPietro PiscioneCannot specify default NS instantiation level of InstantiateVnfData data typeAccording to Note 4 of InstantiateVnfData data type: "[...] If none of the two attributes (vnfInstantiationLevelId or targetScaleLevelInfo) are present, the default instantiation level as declared in the VNFD shall be used."
It is not cl...According to Note 4 of InstantiateVnfData data type: "[...] If none of the two attributes (vnfInstantiationLevelId or targetScaleLevelInfo) are present, the default instantiation level as declared in the VNFD shall be used."
It is not clear in which attribute such default instantiation level should be placed.https://forge.etsi.org/rep/nfv/SOL005/-/issues/20pdf files for OpenAPIs v3.x.x wiki page2021-09-02T09:40:25ZVlademir Brussepdf files for OpenAPIs v3.x.x wiki pageThe pdf files for OpenAPIs v3.x.x wiki page (Release 3) shall be created as soon as a tool to generate the files is available. This shall be investigate and when the tool is available the STF team shall be noticed.
The PDF files for Rel...The pdf files for OpenAPIs v3.x.x wiki page (Release 3) shall be created as soon as a tool to generate the files is available. This shall be investigate and when the tool is available the STF team shall be noticed.
The PDF files for Release 2 OpenAPIs (using swagger 2.0) were autogenerated with a tool (compatible with swagger 2.0).
There is not yet such tool compatible with OpenaAPI 3.0 (used for Release 3 SOLs).Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/19Swaggers make the 'Version' field as 'required'; However the SOL spec (SOL013...2022-11-03T07:24:26ZbanerjeesuSwaggers make the 'Version' field as 'required'; However the SOL spec (SOL013) marks 'Version' as optional.List of swagger / yaml files, along with the line numbers:
./src/SOL005/components/SOL005_params.yaml-1-components:
./src/SOL005/components/SOL005_params.yaml-2- parameters:
./src/SOL005/components/SOL005_params.yaml-3- Version:
./...List of swagger / yaml files, along with the line numbers:
./src/SOL005/components/SOL005_params.yaml-1-components:
./src/SOL005/components/SOL005_params.yaml-2- parameters:
./src/SOL005/components/SOL005_params.yaml-3- Version:
./src/SOL005/components/SOL005_params.yaml-4- name: Version
./src/SOL005/components/SOL005_params.yaml-5- description: >
./src/SOL005/components/SOL005_params.yaml:6: Version of the API requested to use when responding to this request.
./src/SOL005/components/SOL005_params.yaml-7- in: header
./src/SOL005/components/SOL005_params.yaml-8- required: true
./src/SOL005/components/SOL005_params.yaml-9- schema:
./src/SOL005/components/SOL005_params.yaml-10- type: string
./src/SOL005/components/SOL005_params.yaml-11-
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-661-# - name: Version
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-662-# description: |
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml:663:# Version of the API requested to use when responding to this request.
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-664-# in: header
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-665-# required: true
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-666-# type: string
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-441-# type: string
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-442-# - name: Version
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-443-# description: |
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml:444:# Version of the API requested to use when responding to this request.
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-445-# in: header
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-446-# required: true
./src/SOL005/NSPerformanceManagement/NSPerformanceManagement.yaml-447-# type: string
That's causing issues with the generated Java code, as the API makes the 'Version' mandatory, and non-compilant with the SOl013 Spec.
--- From Sol013 ---
"The API producer shall support receiving and interpreting the "Version" HTTP header. The API producer shall include
in the response the "Version" HTTP header signaling the used API version, including the "impl" version parameter if
available. If the "impl" version parameter has been omitted in the request, the API producer shall use the combination of
MAJOR, MINOR and PATCH as requested and the highest supported value for the "impl_version" field of the "impl"
version parameter for that combination, if available."
-----