VnfLcmOpOcc compliance test causes "None is not of type 'string'"

Bug #2037046 reported by Koichi Edagawa
This bug affects 1 person
Affects Status Importance Assigned to Milestone

Bug Description

A Tacker compliance test case fails with the error "None is not of type 'string'".

The cause of this error looks similar to the one already reported in [1], but we need to modify different code from that in order to fix this error.


The detail is as below:

<Target test case>


<Error message>

<status status="FAIL" starttime="20230912 04:54:36.835" endtime="20230912 04:54:36.898" critical="yes">ValidationError: Validation error for schema vnfInstances.schema.json: None is not of type 'string'</status>
ValidationError: Validation error for schema VnfLcmOpOcc.schema.json: None is not of type 'string'

<Part of API Response body>

    "seconds": 0.007365999999999999,
    "status": 200,
    "body": {
        "isAutomaticInvocation": false,
        "id": "fb63df72-1749-4c48-86c8-14c7cc7b986f",
        "vnfInstanceId": "2974a950-f04f-47dc-9d12-a83fca038ec4",
        "stateEnteredTime": "2023-09-12 04:05:12+00:00",
        "operationState": "COMPLETED",
        "grantId": null,
        "isCancelPending": false,
        "operation": "INSTANTIATE",
        "startTime": "2023-09-12 04:05:12+00:00",
        "resourceChanges": {
            "affectedVnfcs": [
                    "id": "707c6dfa-3322-4fc3-8155-12f0f32beffa",
                    "vduId": "VDU1",
                    "changeType": "ADDED",
                    "computeResource": {
                        "vimConnectionId": "958b2da1-e32b-45c4-bbb9-672cbd68ec8f",
                        "resourceId": "dc6ea160-37e5-46e8-b56a-61caac9ea448",
                        "vimLevelResourceType": "OS::Nova::Server"
                    "affectedVnfcCpIds": [
                    "addedStorageResourceIds": [
                    "removedStorageResourceIds": null
            "affectedVirtualLinks": [
                    "id": "9df4d342-7efe-4245-8cca-d2e099d0bead",
                    "vnfVirtualLinkDescId": "internalVL1",
                    "changeType": "ADDED",
                    "networkResource": {
                        "vimConnectionId": null,
                        "resourceId": "",
                        "vimLevelResourceType": null
                    "id": "3c0260f6-87f1-4f28-9b7d-9e585b067abc",
                    "vnfVirtualLinkDescId": "net0",
                    "changeType": "ADDED",
                    "networkResource": {
                        "vimConnectionId": null,
                        "resourceId": "1fec052e-75df-42cd-b274-7283f9c57626",
                        "vimLevelResourceType": "OS::Neutron::Net"
            "affectedVirtualStorages": [
                    "id": "19dcc1c3-3f14-4a5e-b3fb-04e48d08db53",
                    "virtualStorageDescId": "VirtualStorage",
                    "changeType": "ADDED",
                    "storageResource": {
                        "vimConnectionId": "958b2da1-e32b-45c4-bbb9-672cbd68ec8f",
                        "resourceId": "cc1c1700-c52f-4f95-9c79-152e94d41df1",
                        "vimLevelResourceType": "OS::Cinder::Volume"

<Possible root cause>

In the body of API response above, the following four variables have "null" value.

 - grantId
 - resourceChanges > affectedVnfcs > removedStorageResourceIds
 - resourceChanges > affectedVirtualLinks > networkResource > vimConnectionId
 - resourceChanges > affectedVirtualLinks > networkResource > vimLevelResourceType

Then, these values are changed from "null" to "None" by JSON library.

On the other hand, NFV-SOL003 v2.6.1 defines these attributes as the cardinality "0...1".
This indicates the pair of key and value should be omitted and also should not exist if the value is meaningless one.

As the result, the validation check in NFV TST api-tests fails due to the mismatch of types between in response body and JSON schema.

Yasufumi Ogawa (yasufum)
Changed in tacker:
importance: Undecided → Medium
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.