...
Bridge - zoom.us/j/824147956
Recording:
TBADCAE_Weekly_10172019.mp4
Attendees:
Host: Vijay Kumar
Image Added
Discussion Topics:
...
| Time (est) | Topics | Requester/Assignee | Notes/Links |
1 |
| Project Status | | START RECORDING PARTICIPANT LIST - Review Action Items from previous week
- Review El-Alto Earlydrop Commitments
Jira Legacy |
---|
server | System Jira |
---|
jqlQuery | labels = El_Alto_Early_Drop and project = "Data Collection, Analytics, and Events" |
---|
count | true |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
|
- 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/
- Documentation
- Repo has been branched
- Component owner to verify version/tag/blueprint reference under documentation repo ( dcaegen2)
Will be branched by10/07
|
2 |
| El-Alto Commitments | | Release candidate EarlyDrop (Code completion and artifact released by August 2, 2019) 5.0.0
- ConfigbindingService
- CloudifyManager
- Bootstrap
- Plugins (k8s, Dmaap)
- ServiceChangeHandler
- InventoryAPI
- DFC
- PM-Mapper
- Deployment Handler
Branching will be done with released component by tomorrow; master branch can be used for Frankfurt work (need minor version updated to avoid conflict with El-Alto patch/bug fixes)
Second/Final El-Alto drop 5.1.0 Docker containers that are finished to be released Aug 30
Code completion and artifact released by Sep 6, 2019 - BlueprintGenerator (DCAEGEN2-1700)
-
TCA -
VESCollector -
SDK -
RESTConf -
Dashboard - HV-VES
- PRH
-
PM-Mapper (minor updates) - DFC
- SON-Handler
- Mapper
Branching/tagging & new CI-job for el-alto COMPLETED for above components
Branching for following completed (same as Dublin) - TCA
- VESCollector
- SDK
- RESTConf
| 3 | DCAE MOD |
|
Ting Lu
Review DCAE Microservice Onboarding & Design (MOD) feature targeted for Frankfurt release ONAP DCAE MOD Architecture Review | 5 | Oparent updates | | Oparent 2.1.0 is available in nexus.onap.org. Projects referencing the common versions defined in oparent should up-rev to 2.1.0. 3 changes from 2.0.0 DCAEGEN2-1822 - oparent version update | 7 3 |
| Frankfurt features | | Review commitments for Frankfurt from DCAE standpoint Frankfurt Release Requirements |
4 |
| DL Handler | | 9DL Handler advancement from POC done in Dublin - Integration with DMaaP
- K8s integration pending
| 8 | VES Adapter | Rimter/Bell Canada | 1) Added plain kafka support 2) Mapping files from class files changed to different FS (config map) DCAE blueprint/spec updates for ONAP/DCAE integration to be worked | Jira Legacy |
---|
server | System Jira |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | DCAEGEN2-1849 |
---|
|
|
5 |
| Security vulnerabilities | | Jira Legacy |
---|
server | System Jira |
---|
columns | key,summary,type,created,updated,due,assignee,reporter,priority,status,resolution |
---|
serverId | 4733707d-2057-3a0f-ae5e-4fd8aff50176 |
---|
key | DCAEGEN2-1808 |
---|
|
|
6 |
| VES spec 7.1.1 updates | | 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. |
7 |
| 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)- Cloudify deployments of service components should include following environments
"Library Enhancement (CBS java sdk - DCAEGEN2-1552, CBS python util - DCAEGEN2-1551) - Verify if the new environment setting for TLS (below) added by K8s plugin is visible within POD.
- CONFIG_BINDING_SERVICE=<cbs_k8s_service_name>
- DCAE_CA_CERTPATH=<path>
- If DCAE_CA_CERTPATH is defined, use the cacert for establishing secure end-point to interface with CBS (port 10443)
- 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
- 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 |
Open Action Items
New Action items
...