CPS-222: Spike: CPS data update options

Table of Contents:

Addresses:

CPS-222 - Getting issue details... STATUS

Investigation into (long and short term) feasibility options for CPS Dta updates.

Some possibilities like:

Setting a single attribute (value) using a xPath
Update a DataNode (yang fragment) by supplying a new DataNode object with update data
1. With children
2. Ignoring children i.e leaving existing child relations intact
Using the Yang Patch (also used in NetConf?)
Replacing complete instance tree

Options 4 and 1 seem the easiest to implement?!

Option 3 was mentioned by the E2E slicing team but I suspect it to be harder and require a further break down of the Yang-Path ‘language’ features

Out of scope: Validation. The intention is that validation will be handled later using separate study/epic/user stories as required

Parsing and validation of data fragment

Problem description

Initial implementation of data insertion expects full data tree to be provided as input then it's being validated and parsed
versus root defined model starting from top level defined container element. The root element of a model is determined
automatically with no extra action required.

When not full data tree but just a fragment is passed as input the validation and subsequent arsing of the data fails
because the structure of data no longer matches the model (if compared from roots).

Solution proposal

ODL Yang Tools library provides an option to define a point within a model which will be used as root when data is validated
and parsed. It requires an appropriate DataSchemaNode instance to be provided to JsonParserStream instance as a custom root point.

It assumes the implementation/update of a following logic:

Extracting the DataSchemaNode (from SchemaContext) matching the xpath requested
Update the YangUtils.parseJsonData(..) method to utilize additional input
Update the DataNodeBuilder logic to accept non-empty xpath when building data from NormalizedNode instance

Alternative solutions - pros and cons

Data Input / Output Consistency

In order to make custom root pointer solution (described above) work properly, it should point to parent of data node being updated.
At the same time the JSON data require to be presented as a single entry explicitly defining a type of a current node.

From other hand when same data node is requested for output (GET) it addressed by direct xpath and value returned is a data
unwrapped (as is: multiple top level elements).

Below is example using a data fragment referencing ran-network2020-08-06.yang model

GET

// xPath: /ran-network/NearRTRIC[@idNearRTRIC='11']/GNBDUFunction[@idGNBDUFunction='1']/NRCellDU[@idNRCellDU='103594001']/attributes/pLMNInfoList[@mcc='310' and @mnc='410']
{ 
   "mcc": "310",
   "mnc": "410",
   "sNSSAIList": [{
       "sNssai": "10000100",
       "status": "INACTIVE",
       "configData": [{
           "configParameter": "maxNumberOfConns",
           "configValue": 5000
        }]
    ]}
}

POST / PATCH

// xPath: /ran-network/NearRTRIC[@idNearRTRIC='11']/GNBDUFunction[@idGNBDUFunction='1']/NRCellDU[@idNRCellDU='103594001']/attributes
{
   "pLMNInfoList": [{
       "mcc": "310",
       "mnc": "410",
       "sNSSAIList": [{
            "sNssai": "10000100",
            "status": "INACTIVE",
            "configData": [{
                "configParameter": "maxNumberOfConns",
                "configValue": 5000
            }]
        }]
    }]
}