cl664y@att.com

Team to focus on closing defects as reported within Daily Issues Report.

On Track - PTLs will update latest status; special follow-up with Andreas/Tao to be done

Documentation (rst) - Rich Bennett  There is a deprecated API failing.  Upgrade to V2 API requires a "Token".   Seeking input from release engineering on best way to provide token. 

cl664y@att.com

•  Helm Chart Transfer: 4 projects have been identified for trial: Log, Policy, APPC and Clamp. Mike Elliott will work with PTL to gather/transfer knowledge and create training materials. Training to be done the week of Jan 14 and PTL to provide their commitment or not by M1 on Jan 17.
  <1-7/2019>: Work in progress. Schedule might shift to another week. Michael will follow-up with Mike. Training will be open to everybody. The objective is that each team will take over the management of their Helm Charts.
  
  
•  K8S: Yang Xu Ensure labs are updated to relevant K8S version
  <1-7/2019>: Ongoing. K8s 1.11.5; Rancher 2.0 - parameters set in the Heat template to bring the VMs related to K8S. 
  
  k8s scripts here https://git.onap.org/integration/tree/deployment/heat/onap-oom
  and secondary here https://git.onap.org/logging-analytics/tree/deploy  - under https://jira.onap.org/browse/OOM-1496
  https://wiki.onap.org/display/DW/Security+Space+Wiki+Access+List
  
  
•  PTLs to provide their inputs concerning Dublin Tool Chain enhancements (

  Jira Legacy
  server System Jira columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key TSC-58

  )
  <1-7/2019> Last chance to submit anything today
•  PTLs to provide their Security SMEs (

  Jira Legacy
  server System Jira columns key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution serverId 4733707d-2057-3a0f-ae5e-4fd8aff50176 key TSC-29

  )
  <1-7/2019> Final call to add Security SMEs before we review and add them to CLM (starting on 1/15)
  

cl664y@att.com

oom values.yaml or integration repo manifest (

if not covered - see TSC 2019-01-10

Quick discussion on nailing down whether we need a yaml override of the deployable

docker image tags in the oom repo (understanding is no) - with the integration docker manifest

(manifest is currently a copy of the oom values.yaml tags - not the reverse)

If not - then we need a documented procedure wiki/RTD on running a derived values.yaml override for the entire system before deployment

AAF is only an example here

https://git.onap.org/oom/tree/kubernetes/aaf/charts/aaf-service/values.yaml?h=casablanca#n28

image: onap/aaf/aaf_service:2.1.8

drives

https://git.onap.org/integration/tree/version-manifest/src/main/resources/docker-manifest.csv?h=casablanca#n11

onap/aaf/aaf_service,2.1.8

<1-7/2019> #Action 1 Integration team to document the procedure.