Some errors in updates of distributed entities attributes using PATCH methods

[ravaga]

I have 2 instances of Orion-LD, and I created 2 CSR in the Broker 1 pointing to Broker 2

{
    "type": "ContextSourceRegistration",
    "id": "urn:aeros:federation:Domain02:infrastructure",
    "information": [
        {
            "entities": [
                {
                    "type": "Domain"
                },
                {
                    "type": "LowLevelOrchestrator"
                },
                {
                    "type": "InfrastructureElement"
                }
            ]
        }
    ],
    "contextSourceInfo": [
        {
            "key": "Authorization",
            "value": "urn:ngsi-ld:request"
        }
    ],
    "mode": "inclusive",
    "operations": [
        "retrieveOps"
    ],
    "hostAlias": "Domain02",
    "management": {
        "localOnly": true
    },
    "endpoint": "192.168.1.25:1026",
    "status": "active",
    "aerosDomain": "Domain02",
    "aerosDomainFederation": true,
    "origin": "cache"
}

{
    "type": "ContextSourceRegistration",
    "id": "urn:aeros:federation:Domain02:services",
    "information": [
        {
            "entities": [
                {
                    "type": "Service"
                },
                {
                    "type": "ServiceComponent"
                },
                {
                    "type": "NetworkPort"
                },
                {
                    "type": "InfrastructureElementRequirements"
                }
            ]
        }
    ],
    "contextSourceInfo": [
        {
            "key": "Authorization",
            "value": "urn:ngsi-ld:request"
        }
    ],
    "mode": "inclusive",
    "operations": [
        "retrieveOps",
        "updateOps",
        "deleteEntity"
    ],
    "hostAlias": "Domain02",
    "management": {
        "localOnly": true
    },
    "endpoint": "192.168.1.25:1026",
    "status": "active",
    "aerosDomain": "Domain02",
    "aerosDomainFederation": true,
    "origin": "cache"
}

According to the defined operations, when I send a HTTP PATCH to /entities/urn:ngsi-ld:Domain:2 or /entities/urn:ngsi-ld:Domain:2/attrs/name to update the name attribute, it shouldn't be updated as only retrieveOps is configured. However, the entity is updated.

Taking a closer look to the logs, it seems that the "urn:aeros:federation:Domain02:services registration, which includes the updateOps operation, is matched.

However, if I send a GET /entities?type=Domain, the proper registration is matched

[ravaga]

Update: if the type is added to the queries (?type=Domain), it works as expected because no registration is matched because of the entity type (urn:aeros:federation:Domain02:services) or the operations (urn:aeros:federation:Domain02:infrastructure). It can be checked in the attached logs.

However, a 204 code is returned instead of an error code although the update operation is not allowed, no registration is matched and the entity doesn't exist locally. Therefore, which error code should return the broker?

• 400: bad request as the operation is not allowed in the registration matching the entity type
• 404: entity not found in the local broker as any registration is matched

[kzangeli]

This is a little but tricky but I believe a 404 should be returned.
I will have a look at it.

[ravaga]

The same happens for DELETE /entities/urn:ngsi-ld:Domain:2: the entity is deleted if the entity type isn't added to the query. However, when adding the entity type, a 404 is returned, so the same should be returned for the PATCH requests.

For DELETE /entities/urn:ngsi-ld:Domain:2/attrs/name, the attribute isn't removed because the deleteAttrs operation isn't included in any registration, so it's working as expected.

[kzangeli]

Yeah, if the broker has no knowledge of the type ...
Think I found an "easy" fix to the problem.

The registration must still be a match, as there is no info on the entity type of the entity to be patched/deleted.
But, if I add the entity type to the forwarded request, the second broker can decide to do nothing if the entity type is a non-match.
That should solve the problem.

[ravaga]

More information about this issue. I think I've found new bugs related with the PATCH /<entityId> and PATCH /<entityId>/attrs/<attrName>.

To give you more context about it, I'm trying to update the serviceComponentStatus attribute of an entity of type ServiceComponent (included in the registration urn:aeros:federation:Domain02:services). This is an example of the entity:

{
    "id": "urn:ngsi-ld:Service:TestLlo:Component:Nginx",
    "type": "ServiceComponent",
    "service": {
        "type": "Relationship",
        "object": "urn:ngsi-ld:Service:TestLlo"
    },
    "serviceComponentStatus": {
        "type": "Relationship",
        "object": "urn:ngsi-ld:ServiceComponentStatus:Starting"
    },
    "containerImage": {
        "type": "Property",
        "value": "nginx:latest"
    }
}

First, I will send HTTP requests to the Broker 2, in which is actually stored the entity

1. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx with the below body -> 204 response and the entity is updated

{
    "serviceComponentStatus": {
        "type": "Relationship",
        "object": "urn:ngsi-ld:ServiceComponentStatus:Running"
    }
}

2. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx?type=ServiceComponent with the same body -> 204 response but the entity is not updated

As you can see, no registration is matched, but the entity is actually stored locally in the Broker...

Furthermore, if I add the local=true parameter, the entity is not found and a 404 is returned.

3. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx/attrs/serviceComponentStatus with the below body -> 404 response but the entity is updated
   Request body:

{
    "type": "Relationship",
    "object": "urn:ngsi-ld:ServiceComponentStatus:Running"
}

Response body:

{
    "registrationId": "urn:aeros:federation:kubeedge:services",
    "title": "Entity Not Found",
    "detail": "urn:ngsi-ld:Service:TestLlo:Component:nginx"
}

4. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx/attrs/serviceComponentStatus?type=ServiceComponent with the same body -> 404 response but the entity is updated

Furthermore, if I add the local=true parameter, it works as expected and a 204 is returned.

Then, I will send HTTP requests to the Broker 1, in which is NOT stored the entity

1. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx -> 204 response and the entity is updated

2. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx?type=ServiceComponent with the same body -> 204 response but the entity is not updated

As before, no registration is matched, so the PATCH request isn't forwarded to the Broker 2.

3. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx/attrs/serviceComponentStatus -> 204 response and the entity is updated

4. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx/attrs/serviceComponentStatus?type=ServiceComponent -> 204 response and the entity is updated

[kzangeli]

Some comments while I look into this.

• Having two registrations makes things a little harder to understand.
  • The reason 'name' is updated even though "its" registration (when no entity type is given) is for 'retrieveOps' only, is because THE OTHER registration is also a hit, and the second "the other" registration has "updateOps".
  • as we've been saying, not giving the entity type is a problem indeed

[ravaga]

After fixing #1803 I have tried again the tests I run for this issue.

HTTP requests to the Broker 2, in which is actually stored the entity

1. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx with the below body -> 204 response and the entity is updated (as previously)
2. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx?type=ServiceComponent -> 204 response and the entity is updated (fixed!)
3. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx/attrs/serviceComponentStatus -> 404 response but the entity is updated (as previously)
4. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx/attrs/serviceComponentStatus?type=ServiceComponent -> 204 response and the entity is updated (as previously)

Furthermore, if I add the local=true parameter, it works as expected and a 204 is returned (as previously)

HTTP requests to the Broker 1, in which is NOT stored the entity

1. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx -> 204 response and the entity is updated (as previously)

2. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx?type=ServiceComponent -> 204 response and the entity is updated (fixed!)

3. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx/attrs/serviceComponentStatus -> 204 response and the entity is updated (as previously)

4. PATCH /urn:ngsi-ld:Service:TestLlo:Component:Nginx/attrs/serviceComponentStatus?type=ServiceComponent -> 404 response and the *entity is not updated

Response body:

{
    "type": "https://uri.etsi.org/ngsi-ld/errors/ResourceNotFound",
    "title": "Entity/Attribute Not Found",
    "detail": "urn:ngsi-ld:Service:TestLlo:Component:Nginx"
}

Logs:

comp=Orion | op=regMatchForEntityCreation.cpp[155]:regMatchForEntityCreation | msg=urn:aeros:federation:cf:services: No Reg Match due to Information Array