1. Project Overview
DCAE platform includes components collectively fulfilling the role of Data Collection, Analytics, and Events generation for ONAP. The architecture of DCAE targets flexible, pluggable, micros-service oriented, model based component deployment and service composition.
DCAE also support multi-site collection and analytics operations which are essential for large ONAP deployments. DCAE components generally fall into two categories: DCAE Platform Components and DCAE Services Components.
DCAE Platform refers the set of controller components which manages the deployment and LCM of the DCAE service components which include all the collectors, analytics and event processor MS.
2. New component capabilities for Dublin, i.e. the functional enhancements
Following new components introduced for Dublin
Event Processors
- DL Handlers integration (DL-Admin, DL-Feeder)
Analytics/RCA
- PM-Subscription Handler
- TCA-Gen2 (STRETCH GOAL)
Platform Enhancements
- DCAE MOD (mod/genprocessor, mod/runtimeapi, mod/distributorapi, mod/onboardingapi , mod/webui - NiFI)
- Acumos-ONAP DCAE adapter (POC)
- OTI (Phase1) - EventProcessor, Event-Handler
3. New or modified interfaces
Architecture diagram - DCAE R6 M1 Release Planning#Highlevelarchitecturediagram
New External interfaces
- MOD (Onboarding API to AcumosAdapter)
- Policy Handler (via DMaaP)
- PM-Subscription Handler (via DMaaP)
- TCA-gen2 (via DMaaP)
Modified interfaces
- VES Collector (security)
- InventoryAPI (MOD Flow support for CLAMP)
If they are modified, are the backwards compatible?
- VESCollector - Yes
- InventoryAPI - Yes
4. Interface naming
5. Reference to the interfaces
Existing platform API's - https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/offeredapis.html
https://onap.readthedocs.io/en/latest/submodules/dcaegen2.git/docs/sections/apis/inventory.html
https://git.onap.org/dcaegen2/services/prh/tree/swagger.yaml
https://git.onap.org/dcaegen2/collectors/ves/tree/swagger_vescollector_1.3.1.yaml
https://git.onap.org/dcaegen2/platform/configbinding/tree/app/app/swagger.yaml
New R6 APIs to be added into RTD - SON-Handler, RESTConf
DCAE R6 M1 Release Planning#APIOutgoingDependencies
6. What are the system limits
Relies on k8s for loadbalancing and scaling. DCAE platform handles the control flow and do not carry the data/event; DCAE service components can be scaled and support state management.
Cloudify is 3rd party product; multi-site feature on community version will be available later in 2019; will be incorporated for E release.
7. Involved use cases, architectural capabilities or functional requirements
- Usecases
- Self Serve Control Loops v2
- Policy Update Notifications
- 5G / OOF SON Enhancement
- 5G / Bulk PM / PM Control
- 5G / Bulk PM / Secure Communication between xNFs and ONAP
- PNF / Plug and Play
8. Platform Maturity Targets
DCAE R6 M1 Release Planning#PlatformMaturity.1
In-addition, following SECCOM activities are being worked for Frankfurt
- Outstanding OJSI Jira (OJSI Tickets Status)
- Java 11 Upgrade (DCAEGEN2-1918) (stretch goal)
- Python 2.x EOL migration support (DCAEGEN2-1519)
- Following additional TSC MUST have requirement will also be worked in this release.
- Document current upgrade component strategy
- SECCOM Perform Software Composition Analysis - Vulnerability tables
- SECCOM Password removal from OOM HELM charts
- No DCAE impacts identified; will handle new charts contribution for MOD to align with Security needs.
SECCOM HTTPS communication vs. HTTP
config-binding-service 30415 dashboard 30418 DCAEGEN2-1972 - Password removal from HELM charts (EPIC)
DCAEGEN2-1973 DCAE Helm chart updates for password removal
DCAEGEN2-1974 Bootstrap pod updates for sourcing password
DCAEGEN2-1975 Cloudify pod updates for sourcing password
DCAEGEN2-1976 Policy-Handler updates for sourcing password
DCAEGEN2-1977 InventoryAPI updates for sourcing password
DCAEGEN2-1978 ServiceChangeHandler updates for sourcing password
9. Listing of new or impacted models used by the project (for information only)
Support for new policy model as required by Model driven control loop requirement.