ONAP Casablanca Lesson Learned and Dublin Process Improvement

Owned by Kenny Paul
Last updated: Nov 24, 2018 by Eric Debeau
2 min read



Just some initial thoughts - We all need to review the ONAP Beijing Lesson Learned and Casablanca Process Improvement to see how many we did/still need to bring forward. -kenny

@Kenny Paul - license awareness:  Every month when Steve runs his code scans we are constantly revisiting the same problems, often in the same repos:

  • Project Clearwater GPL-3.0 code (which is just never, never going to be usable in any ONAP repo)

  • New .csar files getting (re)added with "AT&T Proprietary" notices in them

  • archive files (.zip, .tar.gz, and the like) being dumped in "just in case they are needed". Between RC0 and RC1 a single .wgn file someone committed contained about 1000 third-party Python files under ~15 different licenses.


@Kenny Paul - from Nov 12 PTL meeting

  • Add a process/policy around the cut-off dates in the release cycle for addressing vulnerabilities within the required 60 day window

  • implement a " three strikes rule " to remove a PTL from a project if they fail to attend X number of TSC and PTL meetings w/o a designated proxy..
    Requires a modification to  Section 3.1.3 of the Community document


@Kenny Paul - On-boarding new projects or usecases

  • Improved documentation of who to talk to (which subcommittees) and when to do so. Seems to be more tribal knowledge based versus a clear process.


@Gildas Lanilis Gmail - Make description Field mandatory in JIRA  (for all type of issues)

  • There are too many cases where people neglect to describe the issue they encounter, the expected behavior, the environment they are working one.


@Gildas Lanilis Gmail - Obtain formal engagement from committer prior to M1

  • By M1 Release Planning, PTLs should obtain formal written commitment from "committers" list on their engagement for Dublin Release. (no response from committer must be interpreted as a disengagement)

@Eric Debeau - Provide a better control code chain for Python based code (PEP8, Pylint, Bandit, Coverage) cf TSC-58: Dublin Toolchain ImprovementClosed

@Eric Debeau - Include documentation (RST file) control using doc8 and additional controls (cf Rich Bennett set of tools used to check bad links...)

@Eric Debeau - Swagger API description validation to be included in Gating project (M3) cf DOC-339: Swagger API generation for consolidated REST ReferenceClosed

@Eric Debeau - Enhance Helm chart validation (each project will be responsible to define Helm charts, as a result, we need some control tools to validate the rules defined by OOM team)

@Eric Debeau - Verify Dockerfile. CIA initiative has defined a set of rules to produce Docker images. We should implement some basic tests to verify what is possible (eg list of base images, number of layers...) cf TSC-62: TSC "Must Have" Dublin Requirements - Container OptimizationClosed