Main purpose is to ensure that metric/log collection, correlation & analysis, and closed loop actions are performed closer to the data.
Analytics can be infrastructure analytics, VNF analytics or application analytics. But in Dublin, analytics-as-a-service is proved using infrastructure analytics.
Link to presentation documents : Distributed Analytics-as-a-Service presentations
Why we are terming this as use case instead of functional requirement?
Initially, distributed analytics is projected as 'functional requirement' as it was felt that all existing use-cases can leverage distributed analytics. Due to various reasons such as - not able to leverage DCAE/CLAMP due to resource issues, significant work in basic work to deploy analytics framework and analytics application sucha s deployment & configuration, it was felt to work on this basic work in R4. As part of basic work, existing use cases will not be integrated. This basic work only consists of generic deployment and configuration, which normally does not require enhancements to existing source code. But, it will require creation of new micro-services that would be deployed in cloud regions.
Showcase | Test Environment | Integration Team Liaison |
---|---|---|
Deploy Big Data analytics training framework on multiple cloud-regions | Intel/Windriver Lab, VMware Lab (TBD) | |
Deploy inferencing framework on multiple cloud regions | Intel/Windriver lab | |
Deploy collection services on multiple cloud regions | Intel/Windriver Lab, VMware Lab (TBD) | |
Deploy test analytics application as any other workload | Intel/Windriver Lab, VMware Lab (TBD) |
It was felt that DCAE integration can't happen in R4 due to lack of understanding and resources. Hence the intention is to develop common items in R4 and integrate with DCAE/CLAMP in future releases. But, during Dublin time frame, like to do following though.
Analytics applications in cloud-regions are being treated as any other workloads for following reasons
Project | PTL | JIRA Epic / User Story* | Requirements |
---|---|---|---|
Demo repository |
| ||
Demo repository |
| ||
Multi-VIM/Cloud |
| ||
Multi-VIM/Cloud | Bin Yang | Cloud infra Event/Alert/Alarm/Fault Normalization & Dispatching microservice development (see analytics intent example)
|
*Each Requirement should be tracked by its own User Story in JIRA
Capabilities (corresponding to Intent) Example:
Testing Blockers
there are many flows that can be tested. We have chosen one which we believe is comprehensive.
Scenario:
ONAP translation:
User actions:
Onboarding
Bring up & Configure (to be filled)
# | Test Case | Status |
---|---|---|
1 | There should be a test case for each item in the sequence diagram | |
2 | create additional requirements as needed for each discreet step | |
3 | Test cases should cover entire Use Case | |
4 | Test Cases should include enough detail for testing team to implement the test |
|