2019-10-24 DCAE Meeting Notes

 Time (est)

 Topics

 Requester/Assignee

 Notes/Links

1

Project Status

@Vijay Kumar

START RECORDING

PARTICIPANT LIST

• Release updates

  • https://lf-onap.atlassian.net/wiki/display/DW/Release+Planning#ReleasePlanning-El-AltoRelease

• Review Action Items from previous week

• Review El-Alto Earlydrop Commitments       

  Getting issues...

• Project Status in El-Alto Release

• DCAE Pair Wise Testing for El Alto Release 

• 1: El Alto Release Integration Test Blocking Issues

• INT-1296, INT-1181 (PRH to be re-released; doc updated pending required by EOW), DCAEGEN2-1754, DCAEGEN2-1793 (no new container), DCAEGEN2-1853( PRH staging job)

• El-Alto branch change from "el-alto" to "elalto"

  • "el-alto" marked as READONLY

  • "elalto" will be official ONAP branch for El-Alto release

• CSIT failures - https://jenkins.onap.org/view/dcaegen2/

  • DataFileCollector

  • HV-VES

  • VES

  • PRH  - dcaegen2-master-csit-prh-testsuites

• Documentation

  • Repo has been branched

  • Component owner to verify version/tag/blueprint reference under documentation repo ( dcaegen2)

  • Will be branched by10/07

2

E2E Network slice impact

 @LIN MENG @Swaminathan Seetharaman

Defer to next week

REQ-146: Usecase review/ DCAE impact

DCAEGEN2-1878: Support 5G slicing - E2E network slicing use caseClosed

3

Frankfurt features 

@Vijay Kumar  

Review commitments for Frankfurt from DCAE standpoint

• Frankfurt Release Requirements

• DCAE R6 M1 Release Planning

4

VES spec 7.1.1 updates

 @alok411

Review planned updates for VES 7.1.1

AttServiceSpecification-VesEventListener-v7.1.1 - AG1 DRAFT.docx

VES Event Registration Specification 3.2.1 Draft.docx

• Impacts VES Collector to use new VES schema file (CommonEventFormat_30.1.1.json)

Provide any feedback by 10/24 to @alok411. Targeting formalize/release of VES updates by EOM; will be work with VNFSDK and Modelleing for release.

 5

VES 8.0 updates review

 @alok411

@marge.hillis

Review 8.0 domain updates  (DCAEGEN2-1769: Add stndDefined domain to VES CollectorClosed

• Review mandatory field list if should be classified as optional to consider other similar stream

• cmNotify has consensus; fault (update required to support fault3gpp) being worked.

6

CBS TLS in SDK

@Piotr Wielebski

ticket: https://gerrit.onap.org/r/#/c/dcaegen2/services/sdk/+/94266/

Confluence: TLS support for CBS - Migration Plan

K8s plugin updates (DCAEGEN2-1550)

1. Cloudify deployments of service components should include following environments

2.  

   • CONFIG_BINDING_SERVICE=<cbs_k8s_service_name>

   • DCAE_CA_CERTPATH=/opt/dcae/cacert/cacert.pem  (this will be default unless overridden by component via blueprint)

   • CBS_CONFIG_URL=https://config-binding-service/service_component_all/<scn> 

     • #scn → Unique Servicecomponent name

"Library Enhancement (CBS java sdk - DCAEGEN2-1552, CBS python util - DCAEGEN2-1551)

1. Verify if the new environment setting for TLS (below) added by K8s plugin is visible within POD.

2.  

   • CONFIG_BINDING_SERVICE=<cbs_k8s_service_name>

   • DCAE_CA_CERTPATH=<path>

3. If DCAE_CA_CERTPATH is defined, use the cacert for establishing secure end-point to interface with CBS (port 10443)

   1. An optional CBS_CONFIG_URL will be exposed providing the exact URL to be used for configuration retrieval. Application/Libraries can use this URL directly instead of constructing URL from HOSTNAME (which refers to ServiceComponentName) and CONFIG_BINDING_SERVICE env's.  By default, this URL will use HTTPS CBS interface

4. If TLS env is undefined, use R4 service name and port (10000) to interface with CBS (HTTP)

Note: Libraries should stop using Consul service discovery to find CBS; instead rely on kubernetes DNS name (exposed via env CONFIG_BINDING_SERVICE) and port 10000 for HTTP and 10443 for HTTPS. Service registration on Consul will not be done for CBS TLS service"

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

Option3 preferred; Nokia team will analyze the impact for k8s plugin updates.

 7

Notice: Meeting time change

New meeting time effective from 11/07/2019 (until 03/05/2020) 

Thursday, 10.30 – 11.30 AM EST/3.30 -4.30 PM UTC

 8

Resource commitment for Frankfurt support

 @Vijay Kumar

Contributors  to review and update contacts and jira/component focus under Resources 

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. 

2. 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;