2020-05-13 DCAE Meeting Notes

Vijay Kumar

Release Status  

Frankfurt Milestone Status#RC1

• RC1 - DCAEGEN2-2203
• 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-2219 - DFC's SFTP client doesn't protect from MITM attacks  - Moved to Guilin

Open items from last meeting

Vijay Kumar

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

k8splugin version 2.0.0 will 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 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

• Jira to be created to track - Vijay Kumar  DCAEGEN2-2240 - CBS SDK error OPEN

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

05/06/2020  - Documentation branching and new CI for frankfurt branch will be set up by 5/7

Branching/tagging completed for all DCAE repo except  dcaegen2 (documentation)

Documentation repo branching targetted for 04 May 2020 

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

Vijay Kumar

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

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

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

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