Page Comparison

...

Jira Legacy
server System Jira
serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
key CPS-1301
Jira Legacy
server System Jira
serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
key REQ-1316
Sample Yang Module: https://github.com/YangModels/yang/blob/main/vendor/cisco/xr/534/ietf-inet-types.yan
PoC by Toine Siebelink to insert prefixes based on schemaContext (ODL Model): https://gerrit.nordix.org/c/onap/cps/+/15553
CPS SChema for yang data: CPS Internal Relation DB Schema

Assumptions

#	Assumption	Notes
1	Sample (wanted) output of: `/module1:A/B/module2:C/D`	See also decision #3
2	Prefix can be inserted before each container but this is optional	See RFC...

...

# Issue Notes Decision

1

Performance issue with current solution

Current solution used inefficient query to populate (first) prefix property for ALL fragments although only used for top level

Will be handled by separate Jira already in progress, see

Jira Legacy

server	System Jira
serverId	4733707d-2057-3a0f-ae5e-4fd8aff50176
key	CPS-1326

2

Top level container is not always defined in first module

This might not be required as the first short-term solution is delivered first

Will be handled by separate Jira

Jira Legacy

server	System Jira
serverId	4733707d-2057-3a0f-ae5e-4fd8aff50176
key	CPS-1344

3

Add prefix for container in same module

This is allowed but not done normally. Team concerned about performance issues and impact on URLs when using this

Ahila P 21 Oct 2022 : Prefix is not required for the child modules or nodes, if it carries the same prefix as parent

4

Add prefix to first container when this is not the top level for the module it is defined

retrieve B or C directly (without parent), in that case should the prefix stil be used ie. Module1:/B

Team 21 Oct 2022 Prefix required for top level nodes in output

5

/module1:A/B/module2:C/D
Which module reference should be inserted in the cpaths for 'Module1' and 'Module2'. Prefix or Name, or last token of namespace?!

See sample from https://github.com/YangModels/yang/blob/main/vendor/cisco/xr/534/ietf-inet-types.yang

Code Block

language	xml
title	ietf-inet-types.yang

module ietf-inet-types {

  namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";
  prefix "inet";

(Unfortunately in above example module name and last token of namespace are the same, not sure if this just convention or mandatory
Use 'ietf-inet-types' or 'inet' to insert

CPS Team (made-up) example

Code Block

title	bookstore.yang

module stores {
    yang-version 1.1;
    namespace "org:onap:ccsdk:sample";

    prefix book-store;

Ahila P 21 Oct 2022 It refers to the 'prefix' in the yang model (highlighted in the sample yang model).

module ietf-inet-types {

namespace "urn:ietf:params:xml:ns:yang:ietf-inet-types";

prefix "inet";

6 Prefix for (additional) leaves that are defined in a separate module then the container itself Required, not sure how common this is. DB Solution for this might be quite difficult. Toine's POC should handle it (to be tested)

7 How to handle lists (instead of container) Possibly ignore [@key=value] part. Small neglectable change of same model defined both under same parent... Toine's Poc can be modified to handle this with help from establish regular-expressions from other use cases

8

Performance Considerations

SchemaContext generation is expensive.

Consider distributed cache (already used for other things in CPS) to store resolved paths
Consider normal cache for schemaContext object has they are not serializable)
Consider generating matcher for all possible paths upon SChemaContext creation (would be limited number) and store in (distributed) cache (with a reasonable time to live)

Use Hazelcast to store 'simplified Model' as defined in Poc Toine

9

Is 'prefix' attribute mandatory for any yang module

Ahila P checked Documentation not clear btu in practice creating a yang module

what to do if it is not there

Ahila P to check

Road Map

...

without prefix gives a 'compilation' liek error in PiYang

25 Oct 2022 base in Ahila's feedback we assume it is mandatory.

Meetings

Date	Participants	Topics
25 Oct 2022	Toine Siebelink arne.chrestin Lena Peuker (DT) Ahila P Priyank Maheshwari Joe K	Open Issues, Roadmap, resouring, Wow
28 Nov 2022	Ahila P arne.chrestin Lena Peuker Toine Siebelink Andras Zoltan Kiss Joe K Levente Csanyi Luke Gleeson (Unlicensed) Seán Beirne Tony Finnerty	Ahila P demonstrated her current solution based on storing prefix (module-name) upfront i.e as part of data in fragment table. Pros seems to work for all output use-cases including edge cases such as leaves etc. module name prefix gets inserted in the first level of the output which might not be the top level element in a module. compatible with SDNC behavior (arne.chrestin confirmed too) Cons Client needs to specify prefix when using xPath requests Backward incompatible cpsPath (search) capabilities broken Impacts on performance (unclear) modulename prefix not per Yang RFX(see decision #5) above (TBC) Actions Toine Siebelink to check prefix v. modulename RFC guideline Ahila P store 'xPath-with-prefixes' in a new field in fragment table to maintain backward compatibility Ahila P break down required functionality in smaller user stories including make xPath queries check both possible paths (with and with prefixes) if needed use of prefixes with cpsPatrh functionality performance impact of new solution

Road Map

Team agreed on 2 step approach (first step or short term solution was deemed unnecessary although some of the code develop as part of the PoC can be re-used in the 'proper' DB solution)

~~Short Term solution (no DB Changes)~~
1. ~~No DB changes or DB interaction (after retrieving yang resources) Based on Toine's Poc https://gerrit.nordix.org/c/onap/cps/+/15553~~
2. ~~Lazy loading of 'simplified model'~~
3. Cache simplified Module (for performance reasons) Can built on te solution for
  Jira Legacy
  server System Jira
  serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176
  key CPS-1326
  here https://gerrit.onap.org/r/c/cps/+/131493
4. ~~This solution should handle Leaf (defined in different module) as well~~
Medium term solutionDB-Solution Part 1
1. Update CPS Internal Relation DB Schema and data insert to retain fragment - yang resource relation
2. Modify data retrieval to insert module references as required
3. retain/modify short term solution for leaves-in-separate modules
Long term solutionDB-Solution Part 2
1. Modie schema to store attribute module informat when needed i.e. when not defined in same module as container that owns those leaves
2. Detailed analysis required

Cost estimates

Item

...

Details

...

Total

...

Notes

Short Term Solution

Options

iterator over schemaContext tree to generate (matchers for) all possible paths or 'normalized paths (ie. without list indexes) See also issue #8
wak three using given paths which need to be resolved as needed (and cache once found)

...

DB Solution, Part 1 (containers and list)

Detailed Analysis incl. PoC: 2 man-weeks
DB Updates to store prefix using Liquibase: 4-6 Manweeks
Save Data update (using some of the PoC Code): 1-2 Weeks
Insert Prefix as needed on dat retrieval (using some of the PoC Code): 1 Week
Develop demo model with multiple modules and update CSIT: 1-2 weeks
Performance Test and Tuning if needed: 1 week

14 Man weeks

Excludes ramping-up in CPS

7 people in parallel weeks, still seems optimistic

DB Solution, Part 2 (leaves)

Resourcing

Name

Involvement

Notes

Toine Siebelink

PTL, Manage Jira's, Generaal support

Ahila P

Analysis & Implementation

Analysis details are updated at

Jira Legacy

server	System Jira
serverId	4733707d-2057-3a0f-ae5e-4fd8aff50176
key	CPS-1380

arne.chrestin

PO & Devolvement

Available after next internal product build

Lena Peuker

PO & Devolvement

Available after next internal product build

DB-Insert Based Solution, part 1, Containers and Lists

Each Fragment needs a reference to the relevant module (on DB Level)

...

1. Use POC code to store prefix for each module name & revision
2. Possible a new table linking fragment with yang-resources
3. update yang resource to include prefix filed
Liquibase Upgrade Step(s) include rollback and migration/updating of existing data
Insert prefix as need upon retrieval (using SQL to combine relevant tables as needed)
Consider Performance (ie. need native queries if needed)

Out of scope: leaves with different modules (see part 2)

DB-Insert Based Solution, part 2, Leaves

TBD, decide to analyse this in more detail later once the changes for Part 1 are more clear

Versions Compared

Old Version 8

New Version Current

Key

Assumptions

Road Map

Meetings

Road Map

Cost estimates

Short Term Solution

Resourcing

DB-Insert Based Solution, part 1, Containers and Lists

DB-Insert Based Solution, part 2, Leaves