FIWARE / context.Orion-LD

Context Broker and CEF building block for context data management which supports both the NGSI-LD and the NGSI-v2 APIs
https://www.etsi.org/deliver/etsi_gs/CIM/001_099/009/01.06.01_60/gs_CIM009v010601p.pdf
GNU Affero General Public License v3.0
51 stars 43 forks source link

Some errors in updates of distributed entities attributes using PATCH methods #1673

Open ravaga opened 1 month ago

ravaga commented 1 month ago

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.

image

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

image

ravaga commented 1 month ago

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.

image

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?

kzangeli commented 1 month ago

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

ravaga commented 1 month ago

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 commented 1 month ago

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 commented 2 days ago

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"
    }
}
  1. 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... image

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

  1. 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"
    }
  2. 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.

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

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