Addressing one of the long term goal to simplify the onboarding experience for MS in DCAE. Introducing new MicroService, Onboarding & Design (MOD) Platform in DCAE for Frankfurt, which will replace DCAE-DS currently under SDC
Policy Integration : Enable update flow support via Dmaap
Acumos-DCAE Adapter Integration (POC)
Support ONAP usecases, functional requirement targeted for Frankfurt
Sub-components are repositories and are consolidated in a single centralized place. Edit the Resouce and Repositories in the centralized page.
...
Area
Actual Level
Targeted Level for current Release
How, Evidences
Comments
Performance
1
1
Level 0: no performance testing done
Level 1: baseline performance criteria identified and measured (such as response time, transaction/message rate, latency, footprint, etc. to be defined on per component)
Level 2: performance improvement plan created
Level 3: performance improvement plan implemented for 1 release (improvement measured for equivalent functionality & equivalent hardware)
Stability
2
2
Level 0: none beyond release requirements
Level 1: 72 hour component-level soak test (random test transactions with 80% code coverage; steady load)
Level 2: 72 hour platform-level soak test (random test transactions with 80% code coverage; steady load)
Level 3: track record over 6 months of reduced defect rate
Resiliency
2
2
0 – none
1 – manual failure and recovery (< 30 minutes)
2 – automated detection and recovery (single site)
3 – automated detection and recovery (geo redundancy)
Security
1
1+ (Most DCAE components are complaint; will address remaining in Frankfurt based on resource availability)
Level 0: None
Level 1: CII Passing badge
Including no critical and high known vulnerabilities > 60 days old
Level 2: CII Silver badge, plus:
All internal/external system communications shall be able to be encrypted.
All internal/external service calls shall have common role-based access control and authorization using CADI framework.
Level 3: CII Gold badge
Scalability
1
1
Level 0: no ability to scale
Level 1: supports single site horizontal scale out and scale in, independent of other components
Level 2: supports geographic scaling, independent of other components
Level 3: support scaling (interoperability) across multiple ONAP instances
Manageability
1
1+ (Except logging, all other requirements are met)
Level 1:
All ONAP components will use a single logging system.
Instantiation of a simple ONAP system should be accomplished in <1 hour with a minimal footprint
Level 2:
A component can be independently upgraded without impacting operation interacting components
Component configuration to be externalized in a common fashion across ONAP projects
All existing APIs must be documented in Swagger 2.0
Level 3
Consistent UI across ONAP projects
Usability testing conducted
API Documentation
All new API’s, all external APIs, and all existing API’s that are modified must adhere to the ONAP API Common Versioning Strategy and Documentation Guidelines
List the API this project is expecting from other projects. Prior to Release Planning review, Team Leads must agreed on the date by which the API will be fully defined. The API Delivery date must not be later than the release API Freeze date.
Prior to the delivery date, it is a good practice to organize an API review with the API consumers.
...
Risk identified
Mitigation Plan
Contingency Plan
Cloudify support for Python 3.x not available during Frankfurt timeframe. This impacts migration of Cloudify and associated plugins in Frankfurt (DCAEGEN2-1546)
Continue El-Alto version of Cloudify and Plugins under python 2.7