2020-05-13 DCAE Meeting Notes

Bridge

Meeting pushed by 30 min for May 13, 2020 ; will start at 15.00 UTC

https://zoom.us/j/98967242523 
Meeting ID: 989 6724 2523
One tap mobile
+16465588656,,98967242523# US (New York)

Dial by your location
        +1 646 558 8656 US (New York)
        +1 669 900 6833 US (San Jose)
        877 369 0926 US Toll-free
        855 880 1246 US Toll-free
Meeting ID: 989 6724 2523
Find your local number: https://zoom.us/u/ad1U59khic

Recording:

DCAE_Weekly_05132020.mp4

Attendees:

Host: @Vijay Kumar



Discussion Topics:





 Time (est)

 Topics

 Requester/Assignee

 Notes/Links









START RECORDING

PARTICIPANT LIST

1



Project Status

@Vijay Kumar

Release Status  

Frankfurt Milestone Status#RC1







DCAE Blockers/High priority

type key summary assignee reporter priority status resolution created updated due
Loading...
Refresh



DCAEGEN2-2218 - Deferred to Guilin; pending Security team confirmation

DCAEGEN2-2217 - Fix done on OOM/DMAAP; CLOSED







DCAE Outstanding Jira & MED priority bugs 

DCAEGEN2-2219 - DFC's SFTP client doesn't protect from MITM attacks (Guilin)  -  Plan to disable SFTP; need help with Test

Open items from last meeting

  • DCAEGEN2-2141 - Documentation warning 

2



DCAE bootstrap updates

@Vijay Kumar

Further blueprint updates will be assessed case by case if bootstrap version release is required

05/13/2020 - Bootstrap 1.12.6 (frankfurt) - Released and OOM updates completed

  • SON_handler - 2.0.2  (released)

  • DataFileCollector - TBA

Reference : https://lists.onap.org/g/onap-discuss/message/20046  Blueprint management for Frankfurt - DCAEGEN2-2041

3



CBS TLS in SDK

@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

link to the sourcehttps://docs.onap.org/en/latest/submodules/dcaegen2.git/docs/sections/tls_enablement.html

k8splugin version 2.0.0will automatically mount the CA certificate, in PEM and JKS formats, in the directory /opt/dcae/cacert. It is not necessary to add anything to the blueprint. To get the CA certificates in a different directory, add a tls_info property to the blueprint, set use_tls to false, and set cert_directory to the directory where the CA certs are needed.Whatever directory is used, the following files will be available:

  • trust.jks:A Java truststore containing the AAF CA certificate. (Needed by clients that access TLS-protected servers.)

  • trust.pass: A text file with a single line that contains the password for thetrust.jks keystore.

  • cacert.pem: The AAF CA certificate, in PEM form. (Needed by clients that access TLS-protected servers.)

k8splugin version 2.0.0 uses an init container to supply the CA certificates.

4/29, 4/1 -tested on HV-VES 1.4.0-not workingException 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

Jira to be created to track - @Vijay KumarDCAEGEN2-2240-CBS SDK error OPEN



5/13/ - after my investigation:

  • CBS client works with k8s 2.0.0 plugin (attached log shows it)

  • HV-VES requires the following certificates: trust.jks & trust.pass, cert.jks & cert.pass

  • When certs are missing HV-VES is throwing an error ( | ERROR | Failed to create configuration: Could not read password from /etc/ves-hv/ssl/jks.pass )

Conclusion:

  • HV-VES is a server app (just like PRH) 

  • use_tls: true, is already set for Frankfurt (so everything should work)

  • I think we can close this case



4



Repo Branching 



All repository branched including documentation (dcaegen2).  Committer must ensure new submissions are cherrypicked into Frankfurt branch

  • 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

6



AAF change impact

@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)

  • one option is for separate truststore for external (discussed under CMPv2)

  • resolve the ownership for current cert/truststore to non-root user (common onap usergroup + and add into separate container)

    • change aaf_agent to default to non-root

DCAE change to be assessed based on CMPv2 proposal; generic onap/usergroup to be discsussed with AAF team - @Vijay Kumar

7



Certificate for components/instance (wild card support)

>Frankfurt

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

5/13 - John Franey/AAF confirmed wild card supported in AAF.  Application can use AAF GUI to modify the SAN's (or bootstrap them via AAF/Windriver test). 

4/29 - Policy may be using wildcard - *.pdp, *.pdp.onap.svc.cluster.local ; to be confirmed if supported from AAF currently @Vijay Kumar

2/20  - DCAEGEN2-2084 - support certificate generation at instance level for DCAE services OPEN to track this request for DCAE; AAF dependency will be discussed post Frankfurt and corresponding AAF Jira to be created

8



Guilin Items

@Vijay Kumar

DCAE Guilin Priorities

Platform 

  • Plugin migration from CCSDK to DCAE (CCSDK-2325 & DCAEGEN2-2207 )

  • K8S plugin optimization   (DCAEGEN2-2215 - allow env support for docker_config, DCAEGEN2-1791 - Switch to containerizedServiceComponent nodetype); bpgen (Jira to be ref)

  • Plugin/type file import (DCAEGEN2-1789)



Requirements from OOM team to be discussed with team

  • All logs to STDOUT

  • AAF integration must be configurable





VES topic/question

@Ravi Ravi

discussed VESCollector related question

  • VEScollection publishes on single partition currently. DCAEGEN2-1484- in backlog to support multiple/dynamic partitions.







@Vijay Kumar

Next meeting will be on 05/27 (05/20 meeting will be cancelled) 

Frankfurt Artifacts Release versions

Check "Artifacts released" section under RTD - https://docs.onap.org/en/latest/submodules/dcaegen2.git/docs/sections/release-notes.html

Open Action Items

#6 -DCAE change to be assessed based on CMPv2 proposal; generic onap/usergroup to be discsussed with AAF team - @Vijay Kumar

New Action items



Seeking Community support

Topic/JIRA

Current Status

 Planned Work

Topic/JIRA

Current Status

 Planned Work

Docker build consistentency ( DCAEGEN2-1579)

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

Need volunteer from community to support

  • Standardize pom/jjb template for all dcae component (java and python)

    • Plugin list alignment with oparent

    • Python build dependency on script to be reduced;