2018-10-31 Meeting notes (SDN-R)

Owned by Martin Skorupski
Nov 03, 2018
2 min read

Date

Oct 31, 2018 

Special guest

  • @Dan Timoney

Goals

  • SDN-C and CC-SDK guidance for SDN-R:

Notes


... by N. K. Shankaranarayanan from presentation by @Dan Timoney, PTL, SDN-C/CCSDK

  • SDN-C and DCAE both had controllers. Efforts were merged to create CC-SDK.

  • Service Logic Interpreter (sli) is very relevant to Directed Graphs (DG) used in SDN-C.

  • ONAP CCSDK gerrit: https://gerrit.onap.org/r/#/admin/projects/?filter=ccsdk

  • ccsdk/parent has all the parent POMs. The root pom of all SDN-R applications should have as parent a ccsdk/parent pom to standardize applications and there development.

  • ccsdk/apps are for apps that run on their own Docker container. SDN-R is currently here. That is ok. But if it makes heavy use of DG etc. It should probably be refactored and put in sli.

  • As per Architecture guidance, all Java code needed will be in CCSDK

  • /distribution builds all the containers

  • /features was created for northbound interfaces for SDN-R.

  • For POC, SDNR is putting code in /features and use that to load in SDN-C.

  • Please see:https://lf-onap.atlassian.net/wiki/display/DW/Resources+and+Repositories


RULES:

  • group has to match

  • ONAP is release under Apache license. Need to have right license header. See example below. Some others also have a modification line.


CODE REVIEWS:

  • Review size: Normally, code submitted for review should not be larger than 2000 lines. But this is really meant for small changes. SDNR is a mature project with things already built. SDNR team may not be forced to limit to 2000 lines. But if code can be separated, that would be good.

  • Suggest 2-person teamwork. One person submits, and one other person does +1 to approve. Then Dan Timoney (one of the reviewers) knows it is ready to review.

 

ONAP milestones:

  • See https://lf-onap.atlassian.net/wiki/display/DW/Release+Planning

  • Don’t yet have dates for Dublin. (first guess: replace 2017 by 2018 for Beijing dates)

  • Dates listed are final approval dates in TSC (Thursday) when Release Manager presents. Before this, PTLs have to approve on Tuesday before. This means that last date is Friday before the Thursday. E.g. For M4 code freeze, it is the Friday before the Thursday date.

  • For M1, Dan will insist that user stories should be documented and that people are signed up.

  • For M2: Document all flows between projects and components that are in scope for release. Need to have ladder diagrams and APIs being called. Is it generic resource or LCM?

  • M3: No changes beyond M3 in API and data model, no changes in yang model. Specific process for changes

  • M4: Beyond M4, only code bug fixes should be there.

  • RC0, RC1, RC2 are testing checkpoints.

  • Yang models and data models should be part of CCSDK repo.

  • With POCs, if there is code that were not part of a release, it needs to be become part of next release.