NFV - Network Functions Virtualisation issueshttps://forge.etsi.org/rep/groups/nfv/-/issues2023-10-18T16:30:27Zhttps://forge.etsi.org/rep/nfv/api-tests/-/issues/203[2.7.1][SOL005] - incorrect API call in testcase "GET information about mult...2023-10-18T16:30:27ZPriyanka Bhatia[2.7.1][SOL005] - incorrect API call in testcase "GET information about multiple alarms with filter "id"" Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?id=${alarmId} Get ${apiRoot}/${apiName}/${apiMajorVersion}/alarms?id=${alarmId}https://forge.etsi.org/rep/nfv/api-tests/-/issues/197There is inconsistency between v2.8.1 and v3.3.12023-08-08T16:34:49ZKoichi EdagawaThere is inconsistency between v2.8.1 and v3.3.1It is found that there is an inconsistency in the code between v2.8.1 and v3.3.1 as below.
<api-tests/SOL003/VNFLifecycleManagement-API/InstantiateVNFTask.robot>
[v2.8.1]
```
*** Test Cases ***
Instantiate a vnfInstance
[Documentat...It is found that there is an inconsistency in the code between v2.8.1 and v3.3.1 as below.
<api-tests/SOL003/VNFLifecycleManagement-API/InstantiateVNFTask.robot>
[v2.8.1]
```
*** Test Cases ***
Instantiate a vnfInstance
[Documentation] Test ID: 7.3.1.3.1
... Test title: Post Instantiate Individual VNFInstance
... Test objective: The objective is to instantiate a VNF instance
... Pre-conditions: VNF instance resource is in NOT INSTANTIATED state
... Reference: Clause 5.4.4.3.1 - ETSI GS NFV-SOL 003 [1] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST instantiate individual vnfInstance
Check HTTP Response Status Code Is 202
Check HTTP Response Header Contains Location <==== Inconsistent line
Check Individual VNF LCM operation occurrence operationState is STARTING <==== Inconsistent line
```
[v3.3.1] (v2.6.1 as well)
```
*** Test Cases ***
Instantiate a vnfInstance
[Documentation] Test ID: 7.3.1.3.1
... Test title: Post Instantiate Individual VNFInstance
... Test objective: The objective is to instantiate a VNF instance
... Pre-conditions: VNF instance resource is in NOT INSTANTIATED state
... Reference: Clause 5.4.4.3.1 - ETSI GS NFV-SOL 003 [1] v3.3.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST instantiate individual vnfInstance
Check HTTP Response Status Code Is 202
Check Operation Occurrence Id existence <==== Inconsistent line
```
I think this inconsistency should be resolved by changing code in either version.https://forge.etsi.org/rep/nfv/api-tests/-/issues/196Validating "operationState" gets failure in v2.8.12023-08-08T15:33:51ZKoichi EdagawaValidating "operationState" gets failure in v2.8.1[Problem statement]
In api-tests v2.8.1, the testcase "POST Heal a vnfInstance" fails in validating the variable "operationState".
The following is an output in running the testcase as example.
```
HealVNFTask
========================...[Problem statement]
In api-tests v2.8.1, the testcase "POST Heal a vnfInstance" fails in validating the variable "operationState".
The following is an output in running the testcase as example.
```
HealVNFTask
==============================================================================
POST Heal a vnfInstance :: Test ID: 7.3.1.8.1 Test title: POST Hea... | FAIL |
Resolving variable '${response['body']['operationState']}' failed: TypeError: string indices must be integers
------------------------------------------------------------------------------
HealVNFTask | FAIL |
1 test, 0 passed, 1 failed
```
"POST Heal a vnfInstance" contains a testcase "Check Individual VNF LCM operation occurrence operationState is" to validate "operationState" as below.
<api-tests/SOL003/VNFLifecycleManagement-API/HealVNFTask.robot>
```
POST Heal a vnfInstance
[Documentation] Test ID: 7.3.1.8.1
... Test title: POST Heal a vnfInstance
... Test objective: The objective is to test that POST method heal a VNF instance
... Pre-conditions: the VNF instance resource is not in NOT-INSTANTIATED state
... Reference: Clause 5.4.9.3.1 - ETSI GS NFV-SOL 003 [1] v2.8.1
... Config ID: Config_prod_VNFM
... Applicability: none
... Post-Conditions: none
POST Heal VNF
Check HTTP Response Status Code Is 202
Check HTTP Response Header Contains Location
Check Individual VNF LCM operation occurrence operationState is STARTING <==== Calling a testcase to validate "operationState"
```
In this testcase, ${response['body']['operationState']} is validated with ${status} at the line (B) as below. The error occurs in this step.
<api-tests/SOL003/VNFLifecycleManagement-API/VnfLcmMntOperationKeywords.robot>
```
Check Individual VNF LCM operation occurrence operationState is
[Arguments] ${status}
Run Keyword If ${AUTH_USAGE} == 1 Set Headers {"${AUTHORIZATION_HEADER}":"${AUTHORIZATION_TOKEN}"}
Get ${response['headers']['Location']} <==== (A)
Log Validate operationState
Log to console ${response}
Should Be Equal as Strings ${response['body']['operationState']} ${status} <==== (B)
Log operationState validated
```
We have also observed that the testcase "POST instantiate individual vnfInstance" gets the same failure.
[Assumed root cause]
The following is our assumption for approaching the root cause.
The line (A) in the above testcase means executing a HTTP request "GET /vnflcm/v1/vnf_lcm_op_occs/{vnfLcmOpOccId}".
The response of this API request contains "operationState". However, this line doesn’t obtain any variables from the response such as the variable "response".
On the other hand, the line (B) expects that "response['body']['operationState’]" contains "operationState". However, there is none in fact, so the equality check always fails.
If this assumption is correct, we can avoid this issue by holding a response value in line (A) like below.
` ${response}= Get ${response['headers']['Location']}`https://forge.etsi.org/rep/nfv/SOL002-SOL003/-/issues/11Superflous file in branch 2.6.1-maintenance2023-03-20T15:22:43ZpostlbauerSuperflous file in branch 2.6.1-maintenanceThe branch contains a file `src/SOL003/VNFPackageManagement/test.yaml` that is a leftover from some experiment (the content shows that it belongs to ETSI MEC)
This file may confuse automatic generation tools using the openapi repository...The branch contains a file `src/SOL003/VNFPackageManagement/test.yaml` that is a leftover from some experiment (the content shows that it belongs to ETSI MEC)
This file may confuse automatic generation tools using the openapi repository and should be removed IMHO
BR,
Juanhttps://forge.etsi.org/rep/nfv/SOL002-SOL003/-/issues/10Wrong reference in src/responses/SOL002SOL003_resp.yaml, branch 2.4.1-mainten...2023-03-20T15:25:28ZpostlbauerWrong reference in src/responses/SOL002SOL003_resp.yaml, branch 2.4.1-maintenanceIn the file mentioned in the issue title, there are many references that try to be "relative" but have an initial slash and become absolute.
I'm referring to lines like 101:
```yaml
$ref: "/../definitions/SOL002SOL003_def.yaml#/de...In the file mentioned in the issue title, there are many references that try to be "relative" but have an initial slash and become absolute.
I'm referring to lines like 101:
```yaml
$ref: "/../definitions/SOL002SOL003_def.yaml#/definitions/ProblemDetails"
```
Here, because it starts with a dash `/` , the `..` can't go higher in the filesystem and it is refering to the absolute path `/definitions/SOL002SOL003_def.yaml` (and then to the ProblemDetails definition inside that file).
Of course this fails, any parser of the openapi specification will give an error similar to
```
[Errno 2] No such file or directory: '/definitions/SOL002SOL003_def.yaml'
```
If we simply remove the extra initial slash, thus having
```yaml
$ref: "/../definitions/SOL002SOL003_def.yaml#/definitions/ProblemDetails"
```
Now we are refering to `src/responses/../definitions/SOL002SOL003_def.yaml` or equivalently `src/definitions/SOL002SOL003_def.yaml`, which is a valid file
Since I can't fork and pull, I'll provide a diff for the fixeshttps://forge.etsi.org/rep/nfv/SOL002-SOL003/-/issues/9[V4.3.1] Incorrect Responce type for vnfLcmOpOccsGet in VnLcmOpOccsApi.java2023-03-17T09:59:21ZVarun Guguloth[V4.3.1] Incorrect Responce type for vnfLcmOpOccsGet in VnLcmOpOccsApi.javaUsing Openapi Code-generator 6.2.1 for "Spring-Boot" (https://github.com/OpenAPITools/openapi-generator) generated the VnfLcmOpOccsApi.java,
the type of response should be `List<VnfLcmOpOcc>` instead of `<VnfLcmOpOcc>`
```
default...Using Openapi Code-generator 6.2.1 for "Spring-Boot" (https://github.com/OpenAPITools/openapi-generator) generated the VnfLcmOpOccsApi.java,
the type of response should be `List<VnfLcmOpOcc>` instead of `<VnfLcmOpOcc>`
```
default ResponseEntity<VnfLcmOpOcc> vnfLcmOpOccsGet(String accept, String version, String authorization, String filter, String allFields, String fields, String excludeFields, String excludeDefault, String nextpageOpaqueMarker) {
getRequest().ifPresent(request -> {
for (MediaType mediaType: MediaType.parseMediaTypes(request.getHeader("Accept"))) {
if (mediaType.isCompatibleWith(MediaType.valueOf("application/json"))) {
String exampleString = "{ \"lcmCoordinations\" : [ \"{}\", \"{}\" ], \"grantId\" : \"grantId\", \"_links\" : \"{}\", \"warnings\" : [ \"warnings\", \"warnings\" ], \"error\" : { \"instance\" : \"instance\", \"detail\" : \"detail\", \"type\" : \"type\", \"title\" : \"title\", \"status\" : 0 }, \"vnfInstanceId\" : \"vnfInstanceId\", \"resourceChanges\" : \"{}\", \"vnfSnapshotInfoId\" : \"vnfSnapshotInfoId\", \"rejectedLcmCoordinations\" : [ \"{}\", \"{}\" ], \"operationParams\" : \"{}\", \"modificationsTriggeredByVnfPkgChange\" : { \"vnfProductName\" : \"vnfProductName\", \"metadata\" : \"{}\", \"extensions\" : \"{}\", \"vnfdVersion\" : \"vnfdVersion\", \"vimConnectionInfo\" : { \"key\" : { \"vimType\" : \"vimType\", \"vimId\" : \"vimId\", \"extra\" : \"{}\", \"interfaceInfo\" : \"{}\", \"accessInfo\" : \"{}\" } }, \"vnfProvider\" : \"vnfProvider\", \"vnfConfigurableProperties\" : \"{}\", \"vnfdId\" : \"vnfdId\", \"vnfSoftwareVersion\" : \"vnfSoftwareVersion\" }, \"stateEnteredTime\" : \"2000-01-23T04:56:07.000+00:00\", \"affectedVipCps\" : [ { \"cpdId\" : \"cpdId\", \"changeType\" : \"ADDED\", \"vnfdId\" : \"vnfdId\", \"cpInstanceId\" : \"cpInstanceId\" }, { \"cpdId\" : \"cpdId\", \"changeType\" : \"ADDED\", \"vnfdId\" : \"vnfdId\", \"cpInstanceId\" : \"cpInstanceId\" } ], \"changedInfo\" : { \"vnfProductName\" : \"vnfProductName\", \"metadata\" : \"{}\", \"extensions\" : \"{}\", \"vimConnectionInfo\" : { \"key\" : { \"vimType\" : \"vimType\", \"vimId\" : \"vimId\", \"extra\" : \"{}\", \"interfaceInfo\" : \"{}\", \"accessInfo\" : \"{}\" } }, \"vnfdVersion\" : \"vnfdVersion\", \"vnfProvider\" : \"vnfProvider\", \"vnfConfigurableProperties\" : \"{}\", \"vnfdId\" : \"vnfdId\", \"vnfInstanceName\" : \"vnfInstanceName\", \"vnfInstanceDescription\" : \"vnfInstanceDescription\", \"vnfSoftwareVersion\" : \"vnfSoftwareVersion\" }, \"changedExtConnectivity\" : [ { \"resourceHandle\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"extNetAttDefResource\" : [ { \"associatedExtCpId\" : [ null, null ], \"netAttDefResource\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"associatedVnfcCpId\" : [ null, null ], \"netAttDefResourceInfoId\" : \"netAttDefResourceInfoId\" }, { \"associatedExtCpId\" : [ null, null ], \"netAttDefResource\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"associatedVnfcCpId\" : [ null, null ], \"netAttDefResourceInfoId\" : \"netAttDefResourceInfoId\" } ], \"extLinkPorts\" : [ { \"resourceHandle\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"secondaryCpInstanceId\" : \"secondaryCpInstanceId\", \"trunkResourceId\" : \"trunkResourceId\", \"id\" : \"id\", \"cpInstanceId\" : \"cpInstanceId\" }, { \"resourceHandle\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"secondaryCpInstanceId\" : \"secondaryCpInstanceId\", \"trunkResourceId\" : \"trunkResourceId\", \"id\" : \"id\", \"cpInstanceId\" : \"cpInstanceId\" } ], \"id\" : \"id\", \"currentVnfExtCpData\" : [ { \"cpdId\" : \"cpdId\", \"cpConfig\" : { \"key\" : { \"linkPortId\" : \"linkPortId\", \"cpProtocolData\" : [ { \"virtualCpAddress\" : { \"loadBalancerIp\" : \"loadBalancerIp\", \"type\" : \"IPV4\" }, \"ipOverEthernet\" : { \"macAddress\" : \"macAddress\", \"segmentationType\" : \"VLAN\", \"ipAddresses\" : [ \"{}\", \"{}\" ], \"segmentationId\" : \"segmentationId\" }, \"layerProtocol\" : \"IP_OVER_ETHERNET\" }, { \"virtualCpAddress\" : { \"loadBalancerIp\" : \"loadBalancerIp\", \"type\" : \"IPV4\" }, \"ipOverEthernet\" : { \"macAddress\" : \"macAddress\", \"segmentationType\" : \"VLAN\", \"ipAddresses\" : [ \"{}\", \"{}\" ], \"segmentationId\" : \"segmentationId\" }, \"layerProtocol\" : \"IP_OVER_ETHERNET\" } ], \"parentCpConfigId\" : \"parentCpConfigId\", \"netAttDefResourceId\" : [ null, null ], \"createExtLinkPort\" : true } } }, { \"cpdId\" : \"cpdId\", \"cpConfig\" : { \"key\" : { \"linkPortId\" : \"linkPortId\", \"cpProtocolData\" : [ { \"virtualCpAddress\" : { \"loadBalancerIp\" : \"loadBalancerIp\", \"type\" : \"IPV4\" }, \"ipOverEthernet\" : { \"macAddress\" : \"macAddress\", \"segmentationType\" : \"VLAN\", \"ipAddresses\" : [ \"{}\", \"{}\" ], \"segmentationId\" : \"segmentationId\" }, \"layerProtocol\" : \"IP_OVER_ETHERNET\" }, { \"virtualCpAddress\" : { \"loadBalancerIp\" : \"loadBalancerIp\", \"type\" : \"IPV4\" }, \"ipOverEthernet\" : { \"macAddress\" : \"macAddress\", \"segmentationType\" : \"VLAN\", \"ipAddresses\" : [ \"{}\", \"{}\" ], \"segmentationId\" : \"segmentationId\" }, \"layerProtocol\" : \"IP_OVER_ETHERNET\" } ], \"parentCpConfigId\" : \"parentCpConfigId\", \"netAttDefResourceId\" : [ null, null ], \"createExtLinkPort\" : true } } } ] }, { \"resourceHandle\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"extNetAttDefResource\" : [ { \"associatedExtCpId\" : [ null, null ], \"netAttDefResource\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"associatedVnfcCpId\" : [ null, null ], \"netAttDefResourceInfoId\" : \"netAttDefResourceInfoId\" }, { \"associatedExtCpId\" : [ null, null ], \"netAttDefResource\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"associatedVnfcCpId\" : [ null, null ], \"netAttDefResourceInfoId\" : \"netAttDefResourceInfoId\" } ], \"extLinkPorts\" : [ { \"resourceHandle\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"secondaryCpInstanceId\" : \"secondaryCpInstanceId\", \"trunkResourceId\" : \"trunkResourceId\", \"id\" : \"id\", \"cpInstanceId\" : \"cpInstanceId\" }, { \"resourceHandle\" : { \"containerNamespace\" : \"containerNamespace\", \"resourceId\" : \"resourceId\", \"vimConnectionId\" : \"vimConnectionId\", \"vimLevelAdditionalResourceInfo\" : { \"hostName\" : \"hostName\", \"persistentVolume\" : \"persistentVolume\", \"additionalInfo\" : \"{}\" }, \"vimLevelResourceType\" : \"vimLevelResourceType\", \"resourceProviderId\" : \"resourceProviderId\" }, \"secondaryCpInstanceId\" : \"secondaryCpInstanceId\", \"trunkResourceId\" : \"trunkResourceId\", \"id\" : \"id\", \"cpInstanceId\" : \"cpInstanceId\" } ], \"id\" : \"id\", \"currentVnfExtCpData\" : [ { \"cpdId\" : \"cpdId\", \"cpConfig\" : { \"key\" : { \"linkPortId\" : \"linkPortId\", \"cpProtocolData\" : [ { \"virtualCpAddress\" : { \"loadBalancerIp\" : \"loadBalancerIp\", \"type\" : \"IPV4\" }, \"ipOverEthernet\" : { \"macAddress\" : \"macAddress\", \"segmentationType\" : \"VLAN\", \"ipAddresses\" : [ \"{}\", \"{}\" ], \"segmentationId\" : \"segmentationId\" }, \"layerProtocol\" : \"IP_OVER_ETHERNET\" }, { \"virtualCpAddress\" : { \"loadBalancerIp\" : \"loadBalancerIp\", \"type\" : \"IPV4\" }, \"ipOverEthernet\" : { \"macAddress\" : \"macAddress\", \"segmentationType\" : \"VLAN\", \"ipAddresses\" : [ \"{}\", \"{}\" ], \"segmentationId\" : \"segmentationId\" }, \"layerProtocol\" : \"IP_OVER_ETHERNET\" } ], \"parentCpConfigId\" : \"parentCpConfigId\", \"netAttDefResourceId\" : [ null, null ], \"createExtLinkPort\" : true } } }, { \"cpdId\" : \"cpdId\", \"cpConfig\" : { \"key\" : { \"linkPortId\" : \"linkPortId\", \"cpProtocolData\" : [ { \"virtualCpAddress\" : { \"loadBalancerIp\" : \"loadBalancerIp\", \"type\" : \"IPV4\" }, \"ipOverEthernet\" : { \"macAddress\" : \"macAddress\", \"segmentationType\" : \"VLAN\", \"ipAddresses\" : [ \"{}\", \"{}\" ], \"segmentationId\" : \"segmentationId\" }, \"layerProtocol\" : \"IP_OVER_ETHERNET\" }, { \"virtualCpAddress\" : { \"loadBalancerIp\" : \"loadBalancerIp\", \"type\" : \"IPV4\" }, \"ipOverEthernet\" : { \"macAddress\" : \"macAddress\", \"segmentationType\" : \"VLAN\", \"ipAddresses\" : [ \"{}\", \"{}\" ], \"segmentationId\" : \"segmentationId\" }, \"layerProtocol\" : \"IP_OVER_ETHERNET\" } ], \"parentCpConfigId\" : \"parentCpConfigId\", \"netAttDefResourceId\" : [ null, null ], \"createExtLinkPort\" : true } } } ] } ], \"startTime\" : \"2000-01-23T04:56:07.000+00:00\", \"id\" : \"id\", \"isAutomaticInvocation\" : true, \"isCancelPending\" : true }";
ApiUtil.setExampleResponse(request, "application/json", exampleString);
break;
}
}
});
return new ResponseEntity<>(HttpStatus.NOT_IMPLEMENTED);
}
```https://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/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/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/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/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/SOL005/-/issues/33In NSDManagement.yaml some parameter descriptions are in schema2022-09-05T08:12:14ZkaidosIn NSDManagement.yaml some parameter descriptions are in schemaI noticed this on 2.7.1-maintenance and 2.8.1. It may be in other branches too. Judging from the other operation parameters as well as the other swagger APIs in the repo this:
```yaml
schema:
$ref: "definitions/SOL005NSDescriptorManag...I noticed this on 2.7.1-maintenance and 2.8.1. It may be in other branches too. Judging from the other operation parameters as well as the other swagger APIs in the repo this:
```yaml
schema:
$ref: "definitions/SOL005NSDescriptorManagement_def.yaml#/definitions/CreateNsdInfoRequest"
description: >
Parameters of creating an NS descriptor resource, as defined in clause 5.5.2.3.
```
Should be like this:
```yaml
schema:
$ref: "definitions/SOL005NSDescriptorManagement_def.yaml#/definitions/CreateNsdInfoRequest"
description: >
Parameters of creating an NS descriptor resource, as defined in clause 5.5.2.3.
```
This may seems superficial but it creates issues with validators/generators.
I have the diff ready but I am `not allowed to push code to this project.`https://forge.etsi.org/rep/nfv/SOL005/-/issues/32Bugzilla [Bug 270] - SOL005_def.yaml DateTime missing type: string2022-09-01T15:42:43ZVlademir BrusseBugzilla [Bug 270] - SOL005_def.yaml DateTime missing type: stringThis issue was reported in Bugzilla tool by Dominique SIDOU in 12/08/2022, as follows:
Bugzilla [Bug 270] - SOL005_def.yaml DateTime missing type: string
SOL005/definitions/SOL005_def.yaml
definitions:
DateTime:
description: >
...This issue was reported in Bugzilla tool by Dominique SIDOU in 12/08/2022, as follows:
Bugzilla [Bug 270] - SOL005_def.yaml DateTime missing type: string
SOL005/definitions/SOL005_def.yaml
definitions:
DateTime:
description: >
Date-time stamp.
Representation: String formatted according toas defined by the date-time production in IETF RFC 3339.
+ type: string
format: date-time
The issue was reported for v3.3.1 but it shall be fixed in all subsequent versions.Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/31Bugzilla [Bug 269] - SOL005NSLifecycleManagement_def.yaml VnfInstanceData.vnf...2022-09-01T15:42:52ZVlademir BrusseBugzilla [Bug 269] - SOL005NSLifecycleManagement_def.yaml VnfInstanceData.vnfProfileId is not requiredThis issue was reported in Bugzilla tool by Dominique SIDOU in 12/08/2022, as follows:
Bugzilla [Bug 269] - Missing requestBody definition in /ns_descriptors/{nsdInfoId}/nsd_content put
SOL005/NSLifecycleManagement/definitions/SOL005NS...This issue was reported in Bugzilla tool by Dominique SIDOU in 12/08/2022, as follows:
Bugzilla [Bug 269] - Missing requestBody definition in /ns_descriptors/{nsdInfoId}/nsd_content put
SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml
vnfProfileId is not required (SOL5 spec alignment)
VnfInstanceData:
type: object
required:
- vnfInstanceId
- - vnfProfileId
+ # - vnfProfileId
The issue was reported for v3.3.1 but it shall be fixed in all subsequent versions.Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/30Bugzilla [Bug 268] - Missing requestBody definition in /ns_descriptors/{nsdIn...2022-09-01T15:42:35ZVlademir BrusseBugzilla [Bug 268] - Missing requestBody definition in /ns_descriptors/{nsdInfoId}/nsd_content putThis issue was reported in Bugzilla tool by Dominique SIDOU in 12/08/2022, as follows:
Bugzilla [Bug 268] - Missing requestBody definition in /ns_descriptors/{nsdInfoId}/nsd_content put
Missing requestBody definition in /ns_descriptors...This issue was reported in Bugzilla tool by Dominique SIDOU in 12/08/2022, as follows:
Bugzilla [Bug 268] - Missing requestBody definition in /ns_descriptors/{nsdInfoId}/nsd_content put
Missing requestBody definition in /ns_descriptors/{nsdInfoId}/nsd_content put:
/ns_descriptors/{nsdInfoId}/nsd_content:
put:
description: |
The PUT method is used to upload the content of an NSD archive. See clause 5.4.4.3.3.
parameters:
- $ref: '#/components/parameters/ContentTypeZip'
parameters:
- $ref: '#/components/parameters/ContentTypeZip'
+ requestBody:
+ content:
+ application/zip:
+ schema:
+ type: string
+ format: binary
The issue was reported for v3.3.1 but it shall be fixed in all subsequent versions.Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/29Bugzilla [Bug 267] - SOL005NSLifecycleManagement_def.yaml, missing underscore...2022-09-01T15:42:15ZVlademir BrusseBugzilla [Bug 267] - SOL005NSLifecycleManagement_def.yaml, missing underscore typo for updateType ADD SAPThis issue was reported in Bugzilla tool by Dominique SIDOU in 12/08/2022, as follows:
Bugzilla [Bug 267] - SOL005NSLifecycleManagement_def.yaml, missing underscore typo for updateType ADD SAP
SOL005/NSLifecycleManagement/definitions/...This issue was reported in Bugzilla tool by Dominique SIDOU in 12/08/2022, as follows:
Bugzilla [Bug 267] - SOL005NSLifecycleManagement_def.yaml, missing underscore typo for updateType ADD SAP
SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml
modified SOL005/NSLifecycleManagement/definitions/SOL005NSLifecycleManagement_def.yaml
@@ -2415,7 +2415,7 @@ definitions:
- MODIFY_VNF_INFORMATION
- CHANGE_EXTERNAL_VNF_CONNECTIVITY
- CHANGE_VNFPKG
- - ADD SAP
+ - ADD_SAP
- REMOVE_SAP
- ADD_NESTED_NS
- REMOVE_NESTED_NS
The issue was reported for v3.3.1 but it shall be fixed in all subsequent versions.Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/28Bugzilla [Bug 260] - NsdInfoModifications: userDefinedData KeyValuePairs of w...2022-09-01T15:42:26ZVlademir BrusseBugzilla [Bug 260] - NsdInfoModifications: userDefinedData KeyValuePairs of wrong typeThis issue was reported in Bugzilla tool by Frank Bryden in 24/08/2020, as follows:
[Bug 260] NsdInfoModifications: userDefinedData KeyValuePairs of wrong type
The NsdInfoModifications datatype contains a section for showing modified u...This issue was reported in Bugzilla tool by Frank Bryden in 24/08/2020, as follows:
[Bug 260] NsdInfoModifications: userDefinedData KeyValuePairs of wrong type
The NsdInfoModifications datatype contains a section for showing modified userDefinedData. According to SOL005, this is of type KeyValuePairs. No issue there.
The OpenAPI specifies the latter datatype to be an array, when SOL013 specifies it must be an object (7.1.5 @ SOL0013v2.7.1).Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/SOL005/-/issues/27NsdInfoModifications: userDefinedData KeyValuePairs of wrong type2022-09-01T15:01:48ZGiacomo BerniniNsdInfoModifications: userDefinedData KeyValuePairs of wrong typecopied from: https://forge.etsi.org/bugzilla/show_bug.cgi?id=260copied from: https://forge.etsi.org/bugzilla/show_bug.cgi?id=260https://forge.etsi.org/rep/nfv/SOL005/-/issues/26Attribute dependency in ExtManagedVirtualLinkData data type2022-08-04T16:59:58ZPietro PiscioneAttribute dependency in ExtManagedVirtualLinkData data typeThe description of intCp attribute of ExtManagedVirtualLinkData data type says: "This attribute may only be present if the "netAttDefResourceData" is also present."
Currently, the Open API Specification does not support the attribute de...The description of intCp attribute of ExtManagedVirtualLinkData data type says: "This attribute may only be present if the "netAttDefResourceData" is also present."
Currently, the Open API Specification does not support the attribute dependency as reported in this issue: https://github.com/OAI/OpenAPI-Specification/issues/256.
However, a possible solution is to use an "intermediate" data type called, for instance, _VnfcConnectionInfo_ that contains two attributes, i.e., netAttDefResourceData (mandatory) and intCp (optional). This _VnfcConnectionInfo_ "intermediate" data type would be then included as an optional attribute in the ExtManagedVirtualLinkData data type, resolving the problem of the attribute dependency. On the other hand, this solution would make the ExtManagedVirtualLinkData, not in compliance with the SOL005ed431 specification.https://forge.etsi.org/rep/nfv/SOL005/-/issues/25Attribute dependency issue on InstantiateVnfData data type2022-08-04T16:59:50ZPietro PiscioneAttribute dependency issue on InstantiateVnfData data typeAccording to Note 6 of the InstantiateVnfData data type: "If the overridingVnfdId attribute is present the vnfProfileId attribute shall also be present.". It means that either both attributes must be defined or none of them.
Currently, ...According to Note 6 of the InstantiateVnfData data type: "If the overridingVnfdId attribute is present the vnfProfileId attribute shall also be present.". It means that either both attributes must be defined or none of them.
Currently, the Open API Specification does not support the attribute dependency as reported in this issue: https://github.com/OAI/OpenAPI-Specification/issues/256.
However, a possible solution is to use an "intermediate" data type called, for instance, _vnfdInfo_ that contains two mandatory attributes, i.e., overridingVnfdId and vnfProfileId. This _vnfdInfo_ "intermediate" data type would be then included as an optional attribute in the VnfInstanceData data model, resolving the problem of the attribute dependency. On the other hand, this solution would make the VnfInstanceData, not in compliance with the SOL005ed431 specification.