Versions Compared

Key

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

...

Recorded Session 2018-06-27

Goals

  • Upcoming milestones
  • Release artifacts
  • Documentation

Discussion items:

Graph Graph to be added to next week's agenda

START RECORDING


PTL ElectionJames Forsyth

PTL elections can be held the week of 2 July 2018. AAI Committers are eligible to vote. PTL term is 1 year.

Casablanca Release Developers Forum Session Proposals


PTL VacationJames ForsythThursdays: [onap-tsc] TSC Meeting ONAP1, Thr UTC 14:00 / China 22:00 / Eastern 10:00 / Pacific 07:00

AAI PTL will be on vacation from 16 July - 27 July 2018. The AAI team will need a delegate to run the Wednesday calls during this time and attend the following calls:

Mondays:

[ptls] Group ONAP1, Mon UTC 13:00 / China 21:00 / Eastern 09:00 / Pacific 06:00

PTL Weekly Meeting #ptl

Thursdays: #tsc TSC Weekly Meeting

Update 27 June: Tian Lee will be the delegate.  James Forsyth to request ONAP Meet 10 Zoom delegation for Tian Lee.


R3 Casablanca CommitmentsJames ForsythAAI R3 M1 Release Planning

Platform Maturity Requirements for Casablanca

Reviewed recommendations from the ONAP F2F meeting - Jason Hunt's slides are here: Casablanca Release Developers Forum Session Proposals

AAI R3 Platform Maturity


API Versioning

AAI is considering the ONAP API Common Versioning Strategy (CVS) Proposal in Dublin

AAI-1185 - Versioning for ONAP Components with Backward Compatibility Open

Christina Monteleone invited to next week's meeting to discuss the restructuring.

Update 6 June: API Versioning has been moved to 1902 release.


AAF and TLS in Casablanca

The AAI team needs a strategy for integrating with AAF and AAF certificate manager, including potentially using 2-way TLS in R3.

AAI-32 - Integrate with AAF Open

Update 6 June: Andy Baxter provided presentation

Update 13 June: Is it necessary to encrypt services behind the reverse proxy (msb/haproxy/kubernetes ingress controller)?


Datagrooming
Andrew Muller and Former user (Deleted)

Champ is coming in Casablanca and will serve as the graph abstraction layer used by resources. Duplicates and other badness happens when multiple nodes are operating on the same objects concurrently. We need to investigate how to use potential locking features or other mechanism to prevent duplicates. Steve Blimkie will look for volunteer inside Amdocs to look for an owner of an Epic that James Forsyth will open in JIRA for Casablanca.

The Datagrooming tool recognizes bad data like duplicates and "phantom nodes"

Venkata Harish Kajur to create a US to document the datagrooming steps/parameters for Beijing.


Casablanca

We'll discuss upcoming Casablanca requirements, get a brief status on the Historical Data Tracking feature.

Update 13 June: Face-2-Face Beijing conference next week; Functional use cases (Schema enhancements), new node types, non-functional requirements and code coverage (70% - 80%) will be output from conference; Evaluate the Kubernetes Ingress Controller as replacement for HAProxy; integrating the services with AAF using Cady.

Update 18 June: Evaluation of Ingress Controller

PROSCONS
  • helm installation with many customizable options
  • easy change and update of routing and config (changing a YAML file)
  • very low maintenance

  • becoming standard in kubernetes

  • easy to expose services outside kubernetes

  • no fine-grained control over different routes within controller
  • might lack some configuration options in comparison with a custom proxy
  • TLS certificates provided through kubernetes

  • obviously not available in docker-only environments
  • current HAproxy adds 14 custom headers - need to look if controller can provide the same headers

Open questions:

  1. Do we need these custom headers in A&AI? They are used only in logging in the resources microservice, no use in code or anything (maybe I missed something?)
  2. Where will we use certificates (proxy/microservices/both)?
  3. Will we use client certificates, if yes who evaluates them (proxy/microservices)?

...


Code Coverage Policy Enforcement

For aai-common, resources, and traversal we've enabled jacoco threshold to make sure that code coverage doesn't fall on a commit. This will prevent users from contributing code that would negatively impact the overall code coverage on a repo. Let's discuss enabling this across the board on all AAI repos.

Update 11 April: James Forsyth and Venkata Harish Kajur - Look at automated PoC polling script, add test coverage.

Update 13 June: Code coverage for Casablanca expected to be 70 - 80% level.

Update 26 June: Code coverage is set to 50% for Casablanca. Need js coverage


CII Badging

Wiki page with instructions on the process: CII Badging Program

We have two CII Badging submissions currently active on CII Best Practice Badge Program: 1) AAI and 2) Sparky-fe

The team needs to decide how to split up the project - AAI is too big to fit under a single project.  James Forsyth proposes the following breakdown for CII badging:

1) AAI core (REST providers and common code): James Forsyth - Project created, ongoing progress.

  • aai-common
  • aai-resources
  • aai-traversal
  • gizmo
  • champ
  • graphadmin
  • event-client

2) GUI - Arul Nambi - Need to include more repos to the current "front-end" project

  • sparky-fe
  • sparky-be
  • data-router
  • search-data-service
  • router-core

3) Model loader - Tian Lee / Mark Tooski- Need to create projects

  • model-loader
  • babel

  • 4) Graph utils / eventing / logging - Steve Blimkie - Need to create projects
  • spike
  • gap - Tian Lee
  • graphgraph - Stretch for Beijing
  • event-client - Tian Lee
  • rest-client

4) ESR - Zi Li - Project is created, still ongoing process to meet all the requirements

  • esr-gui
  • esr-server


The idea is that we assign one key person who will be responsible for getting the badge on their set of repos.  This is just a suggestion, and I invite discussion, re-categorization, and complete rewrites. Owners of the sets can decide whether it makes sense to group sets into one CII badging request, or split. Every repo above must be included in 1 CII submission.

23 Feb:

Need readout next week per repo as to where we stand and how we can close before M4 (3/29).

Zi Li and Arul Nambi will work together to see if same kind of scan will work for both components

2 March: SONAR will not report on java script based so those need to be run manually via another tool locally.

Update 3/8: Urgent - need to document our plan and have a commitment to get to 50% coverage by m4. Preferably sooner to prevent giving your PTL a heart attack.

Offending repos:

ALSO: if your repo is part of Beijing but is NOT part of the SONAR scan, (Venkata Harish Kajur, graphadmin leaps to mind) please fix that ASAP

Update 9 March: Steve Blimkie needs James Forsyth’s signoff on moving small libraries within event and rest clients to aai.core; Spike and Gap not used in Beijing;  Tian Lee to create project for Model loader; may need secondary URL describing model-loader but point to aai.core.

Gizmo – Giulio Graziani requesting adding it to his team's work list.

Common – Venkata Harish Kajur working on

Router-core – AMDOCs to work

Update 16 March: James Forsyth to verify on PTL call if all vulnerabilities 4 or above need to be cleared in order to pass.

Update 21 March: Title of project must have ONAP as the first word; Mark Tooski to pickup Tian Lee's action items while he is out.

Update 4 April: We are at 97%

Update 13 June: CII Badging level for Casablanca to move from Passing to Silver

Update 27 June: Team would like to adopt name of repo included in the label


Action items