openBackhaul / ApplicationPattern

Pattern for REST servers
Apache License 2.0
6 stars 15 forks source link

"OAM Layer Basic Part" service execution fails for specific MWDI services due to other operation-uuid format #977

Closed kmohr-soprasteria closed 1 month ago

kmohr-soprasteria commented 5 months ago

From MWDI issue https://github.com/openBackhaul/MicroWaveDeviceInventory/issues/959:

All paths under "OAM Layer - Basic Part" have the operation-server uuid as path parameter. For the link and link-port service the uuids are a special case and don't follow the normal pattern, but contain "get/put/del" substrings:

# individual services:
        - operation-name: /core-model-1-4:network-control-domain=cache/link={uuid}
          uuid: mwdi-1-1-0-op-s-get-is-205, mwdi-1-1-0-op-s-put-is-205, mwdi-1-1-0-op-s-del-is-205
        - operation-name: /core-model-1-4:network-control-domain=cache/link={uuid}/link-port={localId}
          uuid: mwdi-1-1-0-op-s-get-is-206, mwdi-1-1-0-op-s-put-is-206, mwdi-1-1-0-op-s-del-is-206

I only tried to call the service to change the life-cycle-state and Postman returned an error, but I assume the same problem will occur for all those services, when using any of the above uuids:

  "code": 400,
  "message": "request.params.uuid should match pattern \"^([a-z]{2,6})-([0-9]{1,2})-([0-9]{1,2})-([0-9]{1,2})-op-s-([bi][ms])-([0-9]{3})$\"",
  "errors": [
    {
      "path": ".params.uuid",
      "message": "should match pattern \"^([a-z]{2,6})-([0-9]{1,2})-([0-9]{1,2})-([0-9]{1,2})-op-s-([bi][ms])-([0-9]{3})$\"",
      "errorCode": "pattern.openapi.validation"
    }
  ]
}

During discussion with SIAE, Massimo mentioned that this is a problem that needs to be fixed in the Validator.

PrathibaJee commented 4 months ago

For the following OAM-BasicPart related to operationServers ,

1. /core-model-1-4:control-construct/logical-termination-point={uuid}/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-capability/operation-name
2. /core-model-1-4:control-construct/logical-termination-point={uuid}/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-configuration/life-cycle-state
3. /core-model-1-4:control-construct/logical-termination-point={uuid}/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-configuration/life-cycle-state
4. /core-model-1-4:control-construct/logical-termination-point={uuid}/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-configuration/operation-key
5. /core-model-1-4:control-construct/logical-termination-point={uuid}/layer-protocol=0/operation-server-interface-1-0:operation-server-interface-pac/operation-server-interface-configuration/operation-key

the uuid pattern in the specification is

 pattern: '^([a-z]{2,6})-([0-9]{1,2})-([0-9]{1,2})-([0-9]{1,2})-op-s-([bi][ms])-([0-9]{3})$'

This specified pattern will not accept -get, -put, -del in the following uuids

1. mwdi-1-1-0-op-s-get-is-205, 
2. mwdi-1-1-0-op-s-put-is-205, 
3. mwdi-1-1-0-op-s-del-is-205   
4. mwdi-1-1-0-op-s-get-is-206, 
5. mwdi-1-1-0-op-s-put-is-206, 
6. mwdi-1-1-0-op-s-del-is-206

Proposals to resolve the OAS : Proposal#1 : To solve this problem , In the specifciation of the ApplicationPattern , this pattern of the operationServer's uuid in the OAMLayer shall be modified to ,

^([a-z]{2,6})-([0-9]{1,2})-([0-9]{1,2})-([0-9]{1,2})-op-s(-[a-z]+)?-([bi][ms])-([0-9]{3})$

(-[a-z]+)? is an optional field that will allow both the below formats

Note : Also please check this proposed pattern from your side.

Proposal#2 : To avoid such tight coupling , the uuid pattern in the OAM layers shall be removed because the GET/PUT httpRequest shall not get/modify the resource if they are actually not present in the configuration file.


Temporary Workaround in the server side : To solve the problem in the existing MicroWaveDeviceInventory , in the server/api/openapi.yaml file there are 5 instance of this pattern

^([a-z]{2,6})-([0-9]{1,2})-([0-9]{1,2})-([0-9]{1,2})-op-s-([bi][ms])-([0-9]{3})$ 

which shall be replaced by this pattern

^([a-z]{2,6})-([0-9]{1,2})-([0-9]{1,2})-([0-9]{1,2})-op-s(-[a-z]+)?-([bi][ms])-([0-9]{3})$
kmohr-soprasteria commented 4 months ago

I'd go with proposal#2, because then we are safe in case there are other uuid format changes in the future. However, I'm not familiar enough with how the applications work inside, so we should also get feedback from Thorsten and/or Iswaryaa.

openBackhaul commented 1 month ago

The existing pattern: ^([a-z]{2,6})-([0-9]{1,2})-([0-9]{1,2})-([0-9]{1,2})-op-s-([bi][ms])-([0-9]{3})$ has been replaced by ^([a-z]{2,6})-([0-9]{1,2})-([0-9]{1,2})-([0-9]{1,2})-op-s(-(get|put|post|del|pat))?-([bi][ms])-([0-9]{3})$