Versions Compared

Old Version 2

changes.mady.by.user Toine Siebelink

Saved on

compared with

New Version Current

changes.mady.by.user Toine Siebelink

Saved on

Key

  • This line was added.
  • This line was removed.
  • Formatting was changed.

Table of Contents

References

  1. Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyCPS-1301


  2. Jira
    serverONAP Jira
    serverId425b2b0a-557c-3c0c-b515-579789cceedb
    keyREQ-1316
  3. Sample Yang Module: https://github.com/YangModels/yang/blob/main/vendor/cisco/xr/534/ietf-inet-types.

...

  1. yan
  2. PoC by Toine Siebelink to insert prefixes based on schemaContext (ODL Model): https://gerrit.nordix.org/c/onap/cps/+/15553
  3. CPS SChema for yang data: CPS Internal Relation DB Schema

...

Assumptions

#AssumptionNotes
1Sample (wanted) output of: /module1:A/B/module2:C/DSee also decision #3
2Prefix can be inserted before each container but this is optionalSee RFC...

Issues & Decisions


will check need with her team. whe Image A and B and C are defined in module with prefix X: so full path to C X:/A/B/C  however it is possible to teh use ie. X:Insert prefix or name ()
#IssueNotes Decision
1Performance issue with current solutionCurrent 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
serverONAP Jira
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-1326

2Top level container is not always defined in first moduleThis might not be required as the first short-term solution is delivered first

Will be handled by separate Jira

Jira
serverONAP Jira
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-1344

3Add 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

 : Prefix is not required for the child modules or nodes, if it carries the same prefix as parent

4Add prefix to first container when this is not the top level for the module it is definedretrieve B or C directly (without parent), in that case should the prefix stil be used ie. Module1:/B

Team Prefix required for top level nodes in output

5/module1:A/B/module2:C5/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
languagexml
titleietf-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
titlebookstore.yang
module stores {
    yang-version 1.1;
    namespace "org:onap:ccsdk:sample";

    prefix book-store;


Ahila P   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";

6Prefix for (additional) leaves that are defined in a separate module then the container itselfRequired, not sure how common this is. DB Solution for this might be quite difficult. Toine's POC should handle it (to be tested)
7How 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
8Performance Considerations

SchemaContext generation is expensive. 

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

Short Term Solution

Options

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

...

Use Hazelcast to store 'simplified Model' as defined in Poc Toine
9Is 'prefix' attribute mandatory for any yang module

Ahila P checked Documentation not clear btu in practice creating a yang module without prefix gives a 'compilation' liek error in PiYang

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


Meetings

DateParticipantsTopics

 

Toine Siebelink Arne Chrestin Lena Peuker (DT) Ahila P Priyank Maheshwari Joseph Keenan 

  • Open Issues, Roadmap, resouring, Wow

 

Ahila P Arne Chrestin Lena Peuker Toine Siebelink Andras Zoltan Kiss Joseph Keenan Levente Csanyi Luke Gleeson Sean 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)

  1. 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
      serverONAP Jira
      serverId425b2b0a-557c-3c0c-b515-579789cceedb
      keyCPS-1326
       here https://gerrit.onap.org/r/c/cps/+/131493
    4. This solution should handle Leaf (defined in different module) as well
  2. DB-Solution Part 1
    1. Update  CPS Internal Relation DB Schema and data insert to retain fragment - yang resource relation 
  3. DB-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

ItemDetailsTotalNotes
DB Solution, Part 1 (containers and list)
  1. Detailed Analysis incl. PoC: 2 man-weeks
  2. DB Updates to store prefix using Liquibase: 4-6 Manweeks
  3. Save Data update (using some of the PoC Code): 1-2 Weeks
  4. Insert Prefix as needed on dat retrieval  (using some of the PoC Code): 1 Week
  5. Develop demo model with multiple modules and update CSIT: 1-2 weeks
  6. 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

NameInvolvementNotes
Toine Siebelink 
PTL, Manage Jira's, Generaal support

Ahila P 

Analysis & Implementation

Analysis details are updated at

Jira
serverONAP Jira
serverId425b2b0a-557c-3c0c-b515-579789cceedb
keyCPS-1380

Arne Chrestin 

PO & DevolvementAvailable after next internal product build
Lena Peuker PO & DevolvementAvailable after next internal product build

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

  1. Each Fragment needs a reference to the relevant module (on DB Level)
  2. Consider not removing original prefix's from input (could be caused by ODL parser)

...

    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
  2. Liquibase Upgrade Step(s) include rollback and migration/updating of existing data
  3. Insert prefix as need upon retrieval (using SQL to combine relevant tables as needed)
  4. 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