2020-04-01 DCAE Meeting Notes

Vijay Venkatesh Kumar

• RC0 EPIC - DCAEGEN2-2108
• DCAE Pair Wise Testing for Frankfurt Release

• CSIT failures - https://jenkins.onap.org/view/dcaegen2/   
• Review current list of release artifact version  (screenshot provided at the bottom)
  

DCAE Blockers/High priority

• DCAEGEN2-2120 - Dashboard error on blueprints from inventory (requires fix on runtimeapi and bp-gen + Dashboard + Bootstrap blueprints)
  • Dashboard and Bootstrap released. Bp-gen/RuntimeAPI -  04/01  OOM Fix merged (CLOSED)
• DCAEGEN2-2129 - Public HTTP exposure from DCAE  - Impact remote K8S cluster deployment - Reopened
  • CBS closed
  • VES pending Integration team (OJSI-116)
  • HV-VES -  - 03/25 Fix delivered and OOM update submitted
  • VES  - 04/01 - Fix delivered to OOM; pending to be merged  

• DCAEGEN2-2170 Switch DCAE MOD components to non-root user (related to DCAEGEN2-2121) - 4/1 Pending OOM changes to be merged.
• DCAEGEN2-2171 DL containers running as root(related to DCAEGEN2-2121)  - 4/1 - WIP
• DCAEGEN2-2168  - Support multiple tag for python component using global -  4/1 - CLOSED
• DCAEGEN2-2177 - SCH init-tls container mounts shared volume at wrong mount point - 4/1 - OOM patch merged
• DCAEGEN2-2173,DCAEGEN2-2181, DCAEGEN2-2175 (PMSH) - Fiachra Corcoran will priortize and send email
  

Open items from last week

• DCAEGEN2-2141 - Documentation warning  

• DCAEGEN2-2136  - Cloudify unable to parse certain micro service policies (deferred to Guilin?)

• AAF-1081 : Env issue; blocks DCAEGEN2-2042 Update DCAE certificates (Dashboard, PMSH SAN).
  • Workaround via manual AAF update pending to be checked. Fiachra Corcoran Joseph O'Leary 3/25 - Workaround through manual updated verified; can be documented if 1081 is not delivered by AAF.  4/1 - PMSH documentation to include workaround steps. 
• CLAMP-650 - CLAMP not supporting blueprints (PMSH) with postgres plugin (workaround will be to onboard policy separate and use dashboard/consul)
  • Workaround will not involve CLAMP; so this defect/fix to be checked and moved to Guilin if still issue - David Farrelly  

Vijay Venkatesh Kumar

 Alok Gupta

VES 7.1.1 release

AttServiceSpecification-VesEventListener-v7.1.1 - AG1 DRAFT.docx  - https://gerrit.onap.org/r/#/c/vnfrqts/requirements/+/100867/

VES Event Registration Specification 3.2.1 Draft.docx  - https://gerrit.onap.org/r/#/c/vnfrqts/requirements/+/100876/

Piotr Wielebski

Review recent discussion on : https://gerrit.onap.org/r/#/c/dcaegen2/services/sdk/+/94266/ and identify next step

Confluence: TLS support for CBS - Migration Plan

Current implementation relies on trust.jks being available. Following options to be explored

• Option 1: Work/address issue around using cacert.pem for CBS connection (original proposal)
• Option 2: Enabled use_tls: true for all DCAE MS deployment (in blueprint) to ensure all AAF cert/trust and distributed (regardless of the MS/component being setup as server or not)
• Option 3: Modify K8s plugin to include trust.jks distribution by default along with cacert.pem

Note: Current SDK change https://gerrit.onap.org/r/#/c/dcaegen2/services/sdk/+/94266/ relies on Option#2

3/25 - Test with k8splugin 2.0.0 with use_tls disabled (no blueprint change required for Frankfurt to use this plugin version) - Piotr Wielebski

3/11 - New k8plugin released (2.0.0) and corresponding CM container released. Platform updates completed. Need test of HV_VES with new plugin - Piotr Wielebski

4/1 - tested on HV-VES 1.4.0 - not working - Exception in thread "main" org.onap.dcaegen2.services.sdk.security.ssl.exceptions.ReadingPasswordFromFileException: Could not read password from /etc/ves-hv/ssl/jks.pass   

    - jks.pass is distributed only when use_tls is set to true; need to be checked if app expects cert as server?  Piotr Wielebski  

04/01 - Branching/tagging work to be started for all DCAE components/repo - expected to be completed by next week. Committer must ensure new submissions are cherrypicked into Frankfurt branch

3/25 - Will await TSC plan for RC0 - will review next week and finalize components to branch. For any components needing Guilin work started soon; contact Vijay Venkatesh Kumar  

Repository branching for Frankfurt

• dcaegen2/analytics/tca
• dcaegen2/analytics/tca-gen2
• dcaegen2/collectors/datafile
• dcaegen2/collectors/hv-ves
• dcaegen2/collectors/restconf
• dcaegen2/collectors/snmptrap
• dcaegen2/collectors/ves
• dcaegen2/deployments
• dcaegen2/platform
• dcaegen2/platform/blueprints
• dcaegen2/platform/configbinding
• dcaegen2/platform/deployment-handler
• dcaegen2/platform/inventory-api
• dcaegen2/platform/plugins
• dcaegen2/platform/policy-handler
• dcaegen2/platform/servicechange-handler
• dcaegen2/services
• dcaegen2/services/heartbeat
• dcaegen2/services/mapper
• dcaegen2/services/pm-mapper
• dcaegen2/services/prh
• dcaegen2/services/sdk
• dcaegen2/services/son-handler
• dcaegen2/utils

• Demo scheduled for PMSH and TCA-gen2 -  15 Apr 2020 
• Demo for MOD -  22 Apr 2020  (to be checked if conflict with ONAP Guilin planning meetings)
• Datalake-handler and Acumos Adapter - TBD

Fiachra Corcoran Jack Lucas

aaf_agent (2.1.20) changed in Frankfurt generates cert as non-root; need to assess impact to dcae TLS init (currently uses 2.1.15).

DCAE change will be done post Frankfurt; new userstory to be created - Vijay Venkatesh Kumar

PMSH may need to support multiple instance per different usecase. The certificate generation should be supported at instance level (possible AAF dependency

2/20  - DCAEGEN2-2084 - Getting issue details... STATUS to track this request for DCAE; AAF dependency will be discussed post Frankfurt and corresponding AAF Jira to be created

JIRA cover broad aspect of standardizing DCAE component build process and docker tagging.

1. Nokia team proposal identifies best practice for docker tagging optimized-dockers-jvm.pdf. 
   1. Following components migrated to new docker tagging best-practice
      1. PRH
      2. PM-Mapper