NFV - Network Functions Virtualisation issueshttps://forge.etsi.org/rep/groups/nfv/-/issues2023-03-11T23:43:57Zhttps://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/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.https://forge.etsi.org/rep/nfv/SOL005/-/issues/24Attribute dependency issue in VnfInstanceData and NestedNsInstanceData data t...2022-08-04T16:59:29ZPietro PiscioneAttribute dependency issue in VnfInstanceData and NestedNsInstanceData data typesAccording Note 1 of the VnfInstanceData 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 Ope...According Note 1 of the VnfInstanceData 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.
The same issue affects the NestedNsInstanceData data type.https://forge.etsi.org/rep/nfv/SOL005/-/issues/22Cannot specify default NS instantiation level of InstantiateNsRequest and Cha...2022-08-04T16:59:04ZPietro PiscioneCannot specify default NS instantiation level of InstantiateNsRequest and ChangeVnfFlavourData data typesOn Note 5 of InstantiateNsRequest data type is stated that "[..] If none of the two parameters (nsInstantiationLevelId or targetNsScaleLevelInfo) are present, the default NS instantiation level as declared in the NSD shall be used."
It ...On Note 5 of InstantiateNsRequest data type is stated that "[..] If none of the two parameters (nsInstantiationLevelId or targetNsScaleLevelInfo) are present, the default NS instantiation level as declared in the NSD shall be used."
It is not clear where the default NS instantiation level attribute should be placed.
Same issue for ChangeVnfFlavourData data type.https://forge.etsi.org/rep/nfv/api-tests/-/issues/195Bad use of Format String when replacing value of callbackUri attribute2021-10-08T23:32:22ZGiacomo BerniniBad use of Format String when replacing value of callbackUri attributeShould be replaced with Replaced String as we do not use templating in v2.4.1Should be replaced with Replaced String as we do not use templating in v2.4.1Giacomo BerniniGiacomo Berninihttps://forge.etsi.org/rep/nfv/api-tests/-/issues/194Keywords not running when testing Individual VNFInstances SOL003 VNFLifecycle...2021-10-08T01:33:04ZyaoyuyKeywords not running when testing Individual VNFInstances SOL003 VNFLifecycleMangementAPI V2.6.1when testing task PATCH Individual VNFInstance Precondition failed and PATCH Individual VNFInstance Conflict
the keywords Launch another LCM operation and SET etag should run, but in the log file, It seems not runnningwhen testing task PATCH Individual VNFInstance Precondition failed and PATCH Individual VNFInstance Conflict
the keywords Launch another LCM operation and SET etag should run, but in the log file, It seems not runnninghttps://forge.etsi.org/rep/nfv/api-tests/-/issues/193unexpected GET method runs after http code 303 returned in Subscriptions.robo...2021-10-05T10:15:18Zyaoyuyunexpected GET method runs after http code 303 returned in Subscriptions.robot SOL003 VNFLifecycleManagementAPIWhen testing Create a new Subscription - NO-DUPLICATION task,
robot runs GET API after getting 303 in header, and the response value now is from the GET API which cause the task failed.When testing Create a new Subscription - NO-DUPLICATION task,
robot runs GET API after getting 303 in header, and the response value now is from the GET API which cause the task failed.https://forge.etsi.org/rep/nfv/api-tests/-/issues/192Wrong Parameter name in IndividualVNFInstance.robot SOL003 VNFLifecysleManage...2021-10-05T10:15:18ZyaoyuyWrong Parameter name in IndividualVNFInstance.robot SOL003 VNFLifecysleManagementAPIIn `DELETE Individual VNFInstance Conflict` test task
when check resource existence, the API is
`Get ${apiRoot}/${apiName}/${apiVersion}/vnf_instances/${vnfInstanceId}`
it should be
`Get ${apiRoot}/${apiName}/${apiVersion}/vnf_instance...In `DELETE Individual VNFInstance Conflict` test task
when check resource existence, the API is
`Get ${apiRoot}/${apiName}/${apiVersion}/vnf_instances/${vnfInstanceId}`
it should be
`Get ${apiRoot}/${apiName}/${apiVersion}/vnf_instances/${instantiatedVnfInstanceId}`https://forge.etsi.org/rep/nfv/api-tests/-/issues/191[2.7.1] Test NSFaultManagement-API.Alarms Incorrect Schema validation.2021-10-05T10:15:18Zbanerjeesu[2.7.1] Test NSFaultManagement-API.Alarms Incorrect Schema validation.The plugtest validates faultDetails as type 'String'. However, as per the SOL005 2.7.1 spec, the type should be an array-of-string. The screenshot attached depicts the cardinality to be "0..N".
Rest Invocation (Plugtest logs)
---
<pre>
...The plugtest validates faultDetails as type 'String'. However, as per the SOL005 2.7.1 spec, the type should be an array-of-string. The screenshot attached depicts the cardinality to be "0..N".
Rest Invocation (Plugtest logs)
---
<pre>
13:32:10.314 DEBUG "GET /telco/api/nsfm/v2/alarms HTTP/1.1" 200 None
13:32:10.317 TRACE Return: {'body': [{'_links': {'self': {'href': '/telco/api/nsfm/v2/alarms/a761571b-91b8-478e-946c-7b3497eabb65'}},
'ackState': 'UNACKNOWLEDGED',
'alarmRaisedTime': 'Sat Jul 24 00:16:49 GMT 2021',
'eventTime': 'Sat Jul 24 00:17:58 GMT 2021',
'eventType': 'PROCESSING_ERROR_ALARM',
'faultDetails': ['Cannot find vnfInstance Name for vnfInstanceId:"803d3a8c-9957-4c33-8fba-a13c729c0c5b" of an alarm with id:"a761571b-91b8-478e-946c-7b3497eabb65"'],
'faultType': 'Failed to create number of replica(s) after specified number of tries',
'id': 'a761571b-91b8-478e-946c-7b3497eabb65',
'isRootCause': True,
'managedObjectId': '803d3a8c-9957-4c33-8fba-a13c729c0c5b',
'perceivedSeverity': 'WARNING',
'probableCause': 'ProgressDeadlineExceeded'},
{'_links': {'self': {'href': '/telco/api/nsfm/v2/alarms/b85dba2e-978c-4d11-94dd-642b4270c719'}},
'ackState': 'UNACKNOWLEDGED',
'alarmRaisedTime': 'Sat Jul 24 01:22:35 GMT 2021',
'eventTime': 'Sat Jul 24 01:22:59 GMT 2021',
'eventType': 'PROCESSING_ERROR_ALARM',
'faultDetails': ['Cannot find vnfInstance Name for vnfInstanceId:"1ad2ee08-50d7-4a96-8288-9c1811467c91" of an alarm with id:"b85dba2e-978c-4d11-94dd-642b4270c719"'],
'faultType': 'Failed to create number of replica(s) after specified number of tries',
'id': 'b85dba2e-978c-4d11-94dd-642b4270c719',
'isRootCause': True,
'managedObjectId': '1ad2ee08-50d7-4a96-8288-9c1811467c91',
'perceivedSeverity': 'WARNING',
'probableCause': 'ProgressDeadlineExceeded'},
{'_links': {'self': {'href': '/telco/api/nsfm/v2/alarms/83e7ed6f-ccd1-4198-a102-55fee45fe7f7'}},
'ackState': 'ACKNOWLEDGED',
'alarmRaisedTime': 'Sat Jul 24 04:12:31 GMT 2021',
'eventTime': 'Sat Jul 24 04:13:00 GMT 2021',
'eventType': 'PROCESSING_ERROR_ALARM',
'faultDetails': ['Cannot find vnfInstance Name for vnfInstanceId:"383f176d-f592-4b49-88dd-3ac69edb3587" of an alarm with id:"83e7ed6f-ccd1-4198-a102-55fee45fe7f7"'],
'faultType': 'Failed to create number of replica(s) after specified number of tries',
'id': '83e7ed6f-ccd1-4198-a102-55fee45fe7f7',
'isRootCause': True,
'managedObjectId': '383f176d-f592-4b49-88dd-3ac69edb3587',
'perceivedSeverity': 'WARNING',
'probableCause': 'ProgressDeadlineExceeded'},
{'_links': {'self': {'href': '/telco/api/nsfm/v2/alarms/109d8d61-7e60-45ff-a3f7-506087fb2ad6'}},
'ackState': 'UNACKNOWLEDGED',
'alarmRaisedTime': 'Sat Jul 24 04:02:27 GMT 2021',
'eventTime': 'Mon Jul 26 18:12:31 GMT 2021',
'eventType': 'PROCESSING_ERROR_ALARM',
'faultDetails': ['Cannot find vnfInstance Name for vnfInstanceId:"383f176d-f592-4b49-88dd-3ac69edb3587" of an alarm with id:"109d8d61-7e60-45ff-a3f7-506087fb2ad6"'],
'faultType': 'Failed to pull image from docker repository',
'id': '109d8d61-7e60-45ff-a3f7-506087fb2ad6',
'isRootCause': True,
'managedObjectId': '383f176d-f592-4b49-88dd-3ac69edb3587',
'perceivedSeverity': 'CRITICAL',
'probableCause': 'ErrImagePull'}],
'headers': {'Cache-Control': 'no-cache, no-store, max-age=0, must-revalidate',
'Connection': 'Keep-Alive',
'Content-Encoding': 'gzip',
'Content-Type': 'application/json',
'Date': 'Thu, 23 Sep 2021 08:02:09 GMT',
'Expires': '0',
'Keep-Alive': 'timeout=5, max=100',
'Pragma': 'no-cache',
'Server': 'Apache',
'Set-Cookie': 'SESSION=c83359a4-9afd-464d-9833-bab15d0f1d4b; Path=/; Secure; HttpOnly',
'Strict-Transport-Security': 'max-age=31536000 ; includeSubDomains',
'Transfer-Encoding': 'chunked',
'Version': '2.7.1',
'X-Content-Type-Options': 'nosniff',
'X-Frame-Options': 'SAMEORIGIN',
'X-XSS-Protection': '1; mode=block',
'vary': 'accept-encoding',
'x-transaction-id': 'efdf095a-b6e5-41a6-9831-9849da30a2c5'},
'seconds': 0.20025800000000002,
'status': 200}
</pre>
Test Logs:
---
<pre>
13:32:10.342 FAIL ValidationError: Validation error for schema alarms.schema.json: ['Cannot find vnfInstance Name for vnfInstanceId:"803d3a8c-9957-4c33-8fba-a13c729c0c5b" of an alarm with id:"a761571b-91b8-478e-946c-7b3497eabb65"'] is not of type 'string'
</pre>
SOL Spec Screenshot
---
![Screenshot_2021-09-24_at_10.24.05_AM](/uploads/fa3378fc274849e2397555e3fa563a1b/Screenshot_2021-09-24_at_10.24.05_AM.png)