p1RemoveOutOfRangeLevels : parameters input should be an object with nested object inside

[redchy]

Problem
The handling of input parameters for p1RemoveOutOfRangeLevels is wrong.
The required solution applies to all Functions. For the 1.0.1_spec version not treating the nested input correctly would not lead to an issue for p1RemoveOutOfRangeLevels, but in future releases it could be necessary to call additional Functions from inside p1RemoveOutOfRangeLevels (or any of the other Functions) and then parameters for those could not be passed correctly anymore.

Details:

The implementation for p1RemoveOutOfRangeLevels reads the parameters input as a flat object:

const parameterStruct1 = {
  "lower-tx-level-limit": "10",
  "upper-tx-level-limit": "100",
  "lower-rx-level-limit": "1000",
  "upper-rx-level-limit": "10000"
}

But the specification defines parameters as a structured object containing a parameter array of name/value entries:

  "parameters": {
    "function-name": "p1RemoveOutOfRangeLevels",
    "description": "Removes out-of-range level attributes from a performance data slice",
    "is-active": true,
    "parameter": [
      {
        "parameter-name": "lowerTxLevelLimit",
        "purpose": "Lower bound of valid values of the transmit level",
        "owner": "engineering",
        "value": "-30"
      },
      {
        "parameter-name": "upperTxLevelLimit",
        "purpose": "Upper bound of valid values of the transmit level",
        "owner": "engineering",
        "value": "40"
      },
      {
        "parameter-name": "lowerRxLevelLimit",
        "purpose": "Lower bound of valid values of the receive level",
        "owner": "engineering",
        "value": "-129"
      },
      {
        "parameter-name": "upperRxLevelLimit",
        "purpose": "Upper bound of valid values of the receive level",
        "owner": "engineering",
        "value": "-10"
      }
    ],
    "sub-function": []
  }

the structure of the object from here : https://github.com/openBackhaul/DevicePerformanceManagementDataProcessor/blob/develop/spec/Functions/p1StreamPmData/p1LoadParameters/1.0.0/variables.yaml

Expected behavior
The function should parse and use the spec-defined parameters.parameter[] structure (or at least accept it).

Actual behavior
The function appears to only support the flat keys (e.g., "lower-tx-level-limit") and may fail or ignore limits when provided with the spec-compliant structure.

[latta-siae]

Hi @redchy thanks to highlight the issue.

Function anyway is not officially released. Has been merged into develop branch of SIAE team.

I have some doubt about what you are referring to.
from spec of function is reported different.
https://github.com/openBackhaul/DevicePerformanceManagementDataProcessor/blob/develop/spec/Functions/p1StreamPmData/p1ProcessDevice/p1CreateResultCc/p1IterateAiPmSlices/p1RemoveOutOfRangeLevels/1.0.0/variables.yaml

This specs doesn't fit what you are saying.
So I think you must transform data before calling this function.

Hope synch meeting will be setup soon.

[redchy]

Hi @latta-siae
Thanks for the pointer.
you’re correct that the variables.yaml for p1RemoveOutOfRangeLevels shows the limits as lower-tx-level-limit, etc., but it still defines the input as a hierarchical parameters object:

parameters:
  description: 'Hierarchical object holding the parameter settings from {$input#/parameters}'

And the same file explicitly states those limit values are derived from the hierarchical structure, e.g.:

from [/remove-out-of-range-levels/parameters/parameter=lowerTxLevelLimit/value]

So according to the spec, the function should be able to accept the hierarchical parameters.parameter[] structure and extract the limits internally. If a transform/flattening step is required before calling the function, that step should be documented explicitly as part of the contract; otherwise different callers will pass different shapes.

Even if it’s not officially released yet, it’s best to align spec vs implementation now—before other functions/tests depend on the current behavior and it becomes harder to change later

Happy to align in the sync, but I think the spec text supports the concern: input is hierarchical, and the flat values are meant to be resolved from it.

@kmohr-soprasteria @openBackhaul for confirmation

Thanks.

[latta-siae]

Hi @redchy ,

After a deep analysis I understood your point. Some specs has been misunderstood.
I think other 2 functions could be impacted.
I will let inform you when is ready

[redchy]

Hi @latta-siae

Thanks for taking the time to dig into it and for confirming the misunderstanding in the specs.
Agreed , if the same parameter-handling pattern is used elsewhere, it makes sense that other functions may be impacted too.

Looking forward to your update when you’re ready.

Thanks.

[latta-siae]

anyway the format expected as described in the specs is:

    lower-tx-level-limit:
      type: string
      description: >
        'Lower bound of valid values of the transmit level
        from [/remove-out-of-range-levels/parameters/parameter=lowerTxLevelLimit/value]'

so input data as expected will be

parameters: {
 {
   'parameter': 'lowerTxLevelLimit`,
   'value': 100,
}

[redchy]

Thanks for the clarification — I agree with the intent, but just to align terminology with the spec:

The resolved variable is lower-tx-level-limit.
It is derived from the hierarchical parameters list at:

/remove-out-of-range-levels/parameters/parameter=lowerTxLevelLimit/value.

So the input is not a flat lower-tx-level-limit field; it’s a parameters object containing a parameter[] entry whose parameter-name matches lowerTxLevelLimit, e.g.:

"parameters": {
  "parameter": [
    {
      "parameter-name": "lowerTxLevelLimit",
      "value": "100"
    }
  ]
}

In other words, the spec means: resolve the value by searching the parameter list for the entry where parameter-name == lowerTxLevelLimit, then take its value.

And for the schema of parameters object should meet the output schema of p1LoadParameters : https://github.com/openBackhaul/DevicePerformanceManagementDataProcessor/blob/develop/spec/Functions/p1StreamPmData/p1LoadParameters/1.0.0/variables.yaml

[latta-siae]

What I'm complaining is about how to read this structure.

in another interface.yaml there is this spec reagarding ControlConstruct input:

description: 'AirInterfaces - if {$input#/result-cc/logical-termination-point/uuid={uuid}/layer-protocol/local-id/layer-protocol-name}

and about the step of uuid={uuid] the follow is what I get as input.

      "logical-termination-point": [
        {
          "administrative-control": "core-model-1-4:ADMINISTRATIVE_CONTROL_UNLOCK",
          "ltp-in-other-view": [
            "LTP-MWS-LAN-1-XG-SFP",
            "LTP-MAC-TTP-LAN-1-XG-SFP"
          ],
          "client-ltp": [
            "LTP-MAC-TTP-LAN-1-XG-SFP"
          ],
          "transfer-capacity-pac": "",
          "supporting-pc": "",
          "server-ltp": [
            "LTP-MWS-LAN-1-XG-SFP"
          ],
          "ltp-direction": "core-model-1-4:TERMINATION_DIRECTION_BIDIRECTIONAL",
          "uuid": "LTP-ETC-TTP-LAN-1-XG-SFP",
          "operational-state": "core-model-1-4:OPERATIONAL_STATE_ENABLED",

in interface.yaml there aren't mentioned any parameter-name as you refer.

[/remove-out-of-range-levels/parameters/parameter=lowerTxLevelLimit/value]