NFV - Network Functions Virtualisation issueshttps://forge.etsi.org/rep/groups/nfv/-/issues2023-03-13T12:44:10Zhttps://forge.etsi.org/rep/nfv/SOL002-SOL003/-/issues/7[3.6.1] (maybe others). Wrong definition for IpOverEthernetAddressData2023-03-13T12:44:10Zpostlbauer[3.6.1] (maybe others). Wrong definition for IpOverEthernetAddressDataI'm looking at 3.6.1-maintenance, but this maybe happens in other branches too.
Inside `SOL002-SOL003/src/definitions/SOL002SOL003_def.yaml` , the definition for `IpOverEthernetAddressData` is (I think) incorrect.
The condition expresse...I'm looking at 3.6.1-maintenance, but this maybe happens in other branches too.
Inside `SOL002-SOL003/src/definitions/SOL002SOL003_def.yaml` , the definition for `IpOverEthernetAddressData` is (I think) incorrect.
The condition expressed in
> NOTE 2:Exactly one of "fixedAddresses", "numDynamicAddresses" or "ipAddressRange" shall be present.
Should not not apply to IpOverEthernetAddressData, but only to the children of `ipAddresses` (note how the fields are prefixed with ">" in Table 4.4.1.10c-1 of SOL003 v3.6.1). Therefore this condition should moved under `ipAddresses`.
I tried to fork and merge-request but It looks I don't have the right permissions.
So instead I am attaching the following picture showing the difference (please forget about the "kokoro" lines; they are caused by my internal tool that merges all openapi specs in a single file)
![image](/uploads/4cd2a64148e1d08f92070ac772413d0d/image.png)
To the left, the current status. To the right, how it should be. Please note how the lines must be properly reindented after moving them to the right place.
The original block to move is around line 441 in SOL002-SOL003/src/definitions/SOL002SOL003_def.yaml
Please contact me at jpc@hpe.com if further clarification is needed
Edit: I discovered that the oneOf array has one wrong element.
Currently it has `ipAddressRange`but the proper name is `addressRange` (that would be in the last red line at the bottom right of the picture)
CC: @muhammadhhttps://forge.etsi.org/rep/nfv/SOL002-SOL003/-/issues/8[3.6.1] (and maybe others) Wrong definition for IpOverEthernetAddressInfo2023-03-11T23:43:57Zpostlbauer[3.6.1] (and maybe others) Wrong definition for IpOverEthernetAddressInfoA similar problem to the one described in #7 happens also for `IpOverEthernetAddressInfo`
Image shows on the left the current (wrong) situation an on the right how it should be
![image](/uploads/6cd5fe8ccf9cd471c85d5797a28401b5/image.png)A similar problem to the one described in #7 happens also for `IpOverEthernetAddressInfo`
Image shows on the left the current (wrong) situation an on the right how it should be
![image](/uploads/6cd5fe8ccf9cd471c85d5797a28401b5/image.png)https://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/SOL002-SOL003/-/issues/4bad definition for vnfminfo inside vnfpkginfo2023-01-23T12:34:13Zpostlbauerbad definition for vnfminfo inside vnfpkginfoUsing branch 4.3.1-dev (but I saw that in other branches too)
In file src/SOL003/VNFPackageManagement/definitions/SOL003VNFPackageManagement_def.yaml
You can see:
definitions -> VnfPkgInfo -> properties -> vnfmInfo (at line 136)...Using branch 4.3.1-dev (but I saw that in other branches too)
In file src/SOL003/VNFPackageManagement/definitions/SOL003VNFPackageManagement_def.yaml
You can see:
definitions -> VnfPkgInfo -> properties -> vnfmInfo (at line 136)
```yaml
vnfmInfo:
description: >
Specifies VNFMs compatible with the VNF. This information is copied from the VNFD. See note 3.
$ref: "../../General_Definitions/SOL003_def.yaml#/definitions/String"
```
So this is defined as a string in the OpenAPI specs.
But SOL003 section 10.5.2.2 defines this as an array of strings (cardinality 1..N)
So I think that the file should say
```yaml
vnfmInfo:
description: >
Specifies VNFMs compatible with the VNF. This information is copied from the VNFD. See note 3.
type: array
items:
$ref: "../../General_Definitions/SOL003_def.yaml#/definitions/String"
```https://forge.etsi.org/rep/nfv/SOL002-SOL003/-/issues/5Bad definition for Checksum type2023-01-23T12:33:49ZpostlbauerBad definition for Checksum typeFor both `/src/SOL003/General_Definitions/SOL003_def.yaml` and `src/SOL002/General_Definitions/SOL002_def.yaml`
They not have the proper definition for the Checksum type
```yaml
Checksum: #no definition found
description: >
...For both `/src/SOL003/General_Definitions/SOL003_def.yaml` and `src/SOL002/General_Definitions/SOL002_def.yaml`
They not have the proper definition for the Checksum type
```yaml
Checksum: #no definition found
description: >
Cheksum description
type: string
```
That may be because SOL003 and SOL002 do not define the type by themselves. They refer to SOL004 instead. Incorrectly, I’ll add, as this was moved into SOL013 as of NFVSOL(20)000237r1. Anyway, the proper definition is now in SOL013 section 7.1.7
The yaml equivalent of the defintion would be
```yaml
Checksum:
description: Description should be in sync with SOL013 7.1.7
type: object
required:
- algorithm
- hash
properties:
algorithm:
description: Description should be in sync with SOL013 7.1.7
type: string
hash:
description: Description should be in sync with SOL013 7.1.7
type: string
```https://forge.etsi.org/rep/nfv/SOL006/-/issues/68Updating yang trees2022-12-13T12:27:06ZppreeUpdating yang treesppreeppreehttps://forge.etsi.org/rep/nfv/SOL006/-/issues/67Placement of yang trees in dedicated folder for v3.7.12022-12-13T12:12:34ZppreePlacement of yang trees in dedicated folder for v3.7.1v3.7.1ppreeppreehttps://forge.etsi.org/rep/nfv/SOL011/-/issues/3Query params should not be defined as global parameters in SOL011_params.2022-12-06T16:58:30ZVlademir BrusseQuery params should not be defined as global parameters in SOL011_params.SOL011 is using the same parameters in the file SOL011_params.yaml of the GET methods for all interfaces, but the query parameters can be different for each GET method.
Giacomo answered the following:
“The only open point remains the u...SOL011 is using the same parameters in the file SOL011_params.yaml of the GET methods for all interfaces, but the query parameters can be different for each GET method.
Giacomo answered the following:
“The only open point remains the use of query parameters, for which you are right in some cases they should not be defined as global parameters in SOL011_params.yaml.
Given the fact this issue requires a thorough review of all the OpenAPIs, and most of all that the misalignment with the spec only involves the description field of the query parameters for the various operations, I'd suggest to implement this work for next version of OpenAPIs (i.e. ed361).”Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL011/-/issues/2OpenAPI wiki page - "models" session in "UI" links and "schemas" session in "...2022-12-06T16:58:30ZVlademir BrusseOpenAPI wiki page - "models" session in "UI" links and "schemas" session in "Editor" links.The APIs "SOL011-NSLifecycleOperationGranting-API" and "SOL011-NSInstanceUsageNotification-API" in the OpenAPIs wiki page have:
- UI links – there is a “models” section in OpenAPIs swagger UI pages, this section does not exist in othe...The APIs "SOL011-NSLifecycleOperationGranting-API" and "SOL011-NSInstanceUsageNotification-API" in the OpenAPIs wiki page have:
- UI links – there is a “models” section in OpenAPIs swagger UI pages, this section does not exist in other APIs
- Editor links – there is a “schemas” section in OpenAPIS swagger Editor pages, this section does not exist in other APIs
As these sections are not showed in other APIs there is a need to make them as a standard, the sections need to be removed in SOL011 or included in the other APIs.Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL012/-/issues/3Query params should not be defined as global parameters in SOL012_params.yaml.2022-12-06T15:41:22ZVlademir BrusseQuery params should not be defined as global parameters in SOL012_params.yaml.SOL012 is using the same parameters in the file SOL012_params.yaml of the GET methods for all interfaces, but the query parameters can be different for each GET method.
Giacomo answered the following:
“The only open point remains the u...SOL012 is using the same parameters in the file SOL012_params.yaml of the GET methods for all interfaces, but the query parameters can be different for each GET method.
Giacomo answered the following:
“The only open point remains the use of query parameters, for which you are right in some cases they should not be defined as global parameters in SOL012_params.yaml.
Given the fact this issue requires a thorough review of all the OpenAPIs, and most of all that the misalignment with the spec only involves the description field of the query parameters for the various operations, I'd suggest to implement this work for next version of OpenAPIs (i.e. ed361).”Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL012/-/issues/2OpenAPI wiki page - "models" session in "UI" links and "schemas" session in "...2022-12-06T15:41:22ZVlademir BrusseOpenAPI wiki page - "models" session in "UI" links and "schemas" session in "Editor" links.Same issue in SOL012 v3.4.1 as reported for SOL009 and SOL011.
All APIs in the OpenAPIs wiki page have:
- UI links – there is a “models” section in OpenAPIs swagger UI pages, this section does not exist in other APIs
- Editor link...Same issue in SOL012 v3.4.1 as reported for SOL009 and SOL011.
All APIs in the OpenAPIs wiki page have:
- UI links – there is a “models” section in OpenAPIs swagger UI pages, this section does not exist in other APIs
- Editor links – there is a “schemas” section in OpenAPIS swagger Editor pages, this section does not exist in other APIs
As these sections are not showed in other APIs there is a need to make them as a standard, the sections need to be removed in SOL012 or included in the other APIs.Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL006/-/issues/66Adding Huge page requirements for VM-based VNFs from IFA011ed3712022-11-10T12:11:27ZppreeAdding Huge page requirements for VM-based VNFs from IFA011ed371NFVIFA(22)000629r1NFVIFA(22)000629r1v3.7.1ppreeppreehttps://forge.etsi.org/rep/nfv/SOL006/-/issues/65Addition of Affinity Rule to NS Profile from IFA014ed3712022-11-10T12:10:20ZppreeAddition of Affinity Rule to NS Profile from IFA014ed371NFVIFA(22)000234r1NFVIFA(22)000234r1v3.7.1ppreeppreehttps://forge.etsi.org/rep/nfv/SOL006/-/issues/64Addressing macAddressAssignment from IFA011ed3712022-11-10T12:09:19ZppreeAddressing macAddressAssignment from IFA011ed371NFVIFA(21)0001070r5NFVIFA(21)0001070r5v3.7.1ppreeppreehttps://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."
-----https://forge.etsi.org/rep/nfv/SOL006/-/issues/63Placement of yang trees in dedicated folder2022-10-27T06:54:55ZppreePlacement of yang trees in dedicated folderv4.3.1ppreeppreehttps://forge.etsi.org/rep/nfv/SOL006/-/issues/62Implementation of Mcio data from IFA011ed4312022-10-27T06:54:47ZppreeImplementation of Mcio data from IFA011ed431NFVIFA(22)000012NFVIFA(22)000012v4.3.1ppreeppreehttps://forge.etsi.org/rep/nfv/SOL006/-/issues/61Implementation of Enh02.05 from IFA011ed4212022-10-27T06:54:44ZppreeImplementation of Enh02.05 from IFA011ed421NFVIFA(20)000841r1NFVIFA(20)000841r1v4.3.1ppreeppreehttps://forge.etsi.org/rep/nfv/SOL006/-/issues/60Implementation of ENH02.03 from IFA014 release 4 MegaCR2022-10-27T06:54:41ZppreeImplementation of ENH02.03 from IFA014 release 4 MegaCRNFVIFA(21)000854r1NFVIFA(21)000854r1v4.3.1ppreeppreehttps://forge.etsi.org/rep/nfv/SOL006/-/issues/59Implementation of Enh02.05 from IFA014ed4212022-10-27T06:51:45ZppreeImplementation of Enh02.05 from IFA014ed421NFVIFA(20)000842r3NFVIFA(20)000842r3v4.3.1ppreeppree