...
This is a potential draft of a project proposal template. It is not final or to be used until the TSC approves it.
Project Name:
- Proposed name for the project:
DCAE
- Proposed name for the top level repository name: dcaegen2
- Note: For the 4Q17 release, one of major goals for DCAE is to evolve from the "old" controller that is currently in gerrit.onap.org with a new controller that follows the Common Controller Framework. The switch will maintain external (to other ONAP component) compatibility, but NOT backwards compatible internally. That is, subcomponents built for the old controller will not work with the new controller or vice versa. We are proposing to us a new top level naming “dcaegen2” for repos of subcomponents that are compatible with the new controller because it appears to be the cleanest approach to avoid confusion. The existing "dcae" top level still hosts repos of subcomponent projects that are compatible with the old controller. Eventually we will phase out the "dcae" tree.
- Note: For the 4Q17 release, one of major goals for DCAE is to evolve from the "old" controller that is currently in gerrit.onap.org with a new controller that follows the Common Controller Framework. The switch will maintain external (to other ONAP component) compatibility, but NOT backwards compatible internally. That is, subcomponents built for the old controller will not work with the new controller or vice versa. We are proposing to us a new top level naming “dcaegen2” for repos of subcomponents that are compatible with the new controller because it appears to be the cleanest approach to avoid confusion. The existing "dcae" top level still hosts repos of subcomponent projects that are compatible with the old controller. Eventually we will phase out the "dcae" tree.
Project description:
DCAE is the umbrella name for a number of components collectively fulfilling the role of Data Collection, Analytics, and Events generation for ONAP. The architecture of DCAE targets flexible, plug-able, 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 consists of components that are needed for any deployments. They form the foundation for deploying and managing DCAE Service components, which are deployed on-demand based on specific collection and analytics needs.
DCAE Platform
DCAE Platform consists of a growing list of components. For R1 release this includes the Cloudify Manager, Consul, Dispatcher, Policy Handler, Service Changing Handler, Service Infrastructure (Docker host and CDAP cluster), and CDAP Broker. Their roles and functions are described below:
...
The DCAE platform is expected to be deployed through the ONAP Operations Manager (OOM). There are two ways to deploy a DCAE system: 1. all DCAE components (both Platform and Service components) deployed by the OOM; or 2. the OOM deploys only the core DCAE platform functions, namely the Lifecycle Manager (Cloudify) and the Service & Config Registry (Consul). Then this platform core subsequently deploys all other DCAE Platform components. Note that the platform core is based on the same software tools that are part of the Common Controller SDK just like OOM. Because of the multi-level responsibility structure, option 2 is more suitable for larger DCAE systems that span cross multiple sites and security and infrastructure technology boundaries. We will use the option 2 as example in the DCAE Service component deployment description too.
DCAE Services
DCAE provides data collection and analysis services to the ONAP. Different analysis services will require different collection components and analytics components. They are distinct from DCAE Platform components because they are dynamically deployed and managed based on service needs. More over they are deployed and managed by the DCAE Platform. These are the DCAE Service components.
Under DCAE, the collectors and analytics, either as Docker containers or as CDAP applications, will be on-boarded as Blueprints to the DCAE Platform. At deployment time, as triggered by API calls through Dispatcher and other interfacing Platform modules, the Cloudify Manager completes the deployment of the required DACE DCAE Service resources onto the Docker Host or CDAP Cluster that is determined by the DCAE Platform. The illustration below depicts that the DCAE is deploying two services (yellow and red). The required DCAE Service components are deployed onto the DCAE Platform. In this example, the yellow service is completed by a VNF Event Streaming collector and a Threshold Crossing Analytics; while the red service consists of a SNMP Trap collector, followed by a data normalization step and a Correlation analytics.
...
Dedicated DCAE Portal/GUI is not part of the DCAE project under the current scope. In future if such portal is deemed necessary, it may be developed under DCAE, or under Portal or VID porjectproject. At present time, certain aspects of DCAE operation status can be displayed by utilizing a combination of native GUI/Portal of the open source software tools used by DCAE (e.g. CDAP GUI, Cloudify portal, etc), or CLAMP cockpit for a more service level end-to-end view in which DCAE is only a part, or CLI-style and RestAPI interaction for status probing.
Project Scope:
Because of the large potential scope for DCAE, the components proposed for 4Q17 R1 are prioritized as follows:
...
How does this project fit into the rest of the ONAP Architecture?
DCAE performs a vital function within the ONAP architecture. DCAE collects performance metrics and fault data from the VNFs, PNFs, and computing infrastructure, performing local and global analytics, and generating events that are provided for downstream ONAP components (e.g. Policy) for further operations.DCAE follows the TOSCA model based ONAP Operations Manager and Common Controller SDK architecture for component on-boarding, close-loop triggered or event (e.g. A&AI) triggered collector and analytics deployment, configuration, and scaling.
- What other ONAP projects does this project depend on?
- A&AI, Policy, Micro Services, Modeling, CLAMP, SDC, OOM, CCSDK, DMaaP, Common Services, MultiVIM, Integration, Holmes
- How does this align with external standards/specifications?
- TOSCA
- VES (OPNFV)
- Are there dependencies with other open source projects?
- CDAP, Cloudify, Consul, Hadoop, Elastic Search, PostgreSQL, MariaDB
Resources:
Primary Contact Person
Project Technical Lead
- Current
- Vijay Venkatesh Kumar
- John F. Murray (AT&T)
- Lusheng Ji
- (AT&T)
...
- Past
- Lusheng
- Ji (AT&T)
Names, gerrit IDs, and company affiliations of the committers
Name | Gerrit ID | Company | Time Zone | DCAE Component Focus | |
---|---|---|---|---|---|
Lusheng Ji | wrider | AT&T | lji@research.att.com | New Jersey, USA EST/EDT | |
Vijay Venkatesh Kumar | vv770d | AT&T | New Jersey, USA EST/EDT | collectors controller | |
Tony Hansen | TonyLHansen | AT&T | tony@att.com | New Jersey, USA EST/EDT | database, storage, analytics |
Mike Hwang | researchmike | AT&T | mhwang@research.att.com | New Jersey, USA EST/EDT | controller |
Yan Yang | yangyan | China Mobile | yangyanyj@chinamobile.com | Beijing, China. UTC +8 | collectors |
Xinhui Li | xinhuili | VMware | lxinhui@vmware.com | Beijing, China. UTC +8 | collectors |
Contributors
Names and affiliations of any other contributors
Company | Name | DCAE Component/Repo Focus | Commitment (%) | |||||
AT&T | Alok Gupta | ag1367@att.com | VES | |||||
Gayathri Patrachari | Collector | 50% | ||||||
Alexei Nekrassov | nekrassov@att.com | Analytics | 50% | |||||
Tommy Carpenter | tommy@research.att.com | CDAP Broker, Config binding service | >50% | |||||
Jack Lucas | jflucas@research.att.com | Deployment Handler, Cloudify Manager | >50% | |||||
Alexander V Shatov | alexs@research.att.com | Policy Handler | >50% | |||||
David Ladue | dl3158@att.com | SNMP Trap Collector | 50% | |||||
Gokul Singraju | gs244f@att.com | VES | ||||||
Intel | Maryam Tahhan | VES | ||||||
Tim Verrall | VES | |||||||
China Mobile | Yuan Liu | |||||||
Huawei | Avinash S | |||||||
Actual contribution TBD for below | ||||||||
AT&T | Jerry Robinson | |||||||
BOCO | Jingbo Liu | liujingbo@boco.com.cn | ||||||
Zhangxiong Zhou | ||||||||
Deutsch Telcom | Mark Fiedler | |||||||
Futurewei | Xin Miao | xin.miao@huawei.com | ||||||
IBM | Yusuf Mirza | |||||||
David Parfett | ||||||||
Mathew Thomas | ||||||||
Janki Vora | ||||||||
Amandeep Singh | ||||||||
Orange | Vincent Colas | |||||||
Olivier Augizeau | ||||||||
Pawel Pawlak | ||||||||
Reliance Jio | Aayush Bhatnagar | Aayush.Bhatnagar@ril.com | ||||||
Yog Vashishth | yog.vashishth@ril.com | |||||||
Adityakar Jha | Adityakar.Jha@ril.com | |||||||
Tech Mahindra | Sandeep Singh | |||||||
Abhinav Singh | ||||||||
VMware | Sumit Verdi |
...
- Project Roles (include RACI chart, if applicable)
Other Information
- link to seed code (if applicable)
- Vendor Neutral
- if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
The current seed code has been already scanned and cleanup to remove all proprietary trademarks, logos, etc. except openecomp to be replaced by onap
Subsequent modification to the existing seed code should continue to follow the same scanning and clean up principles.
- if the proposal is coming from an existing proprietary codebase, have you ensured that all proprietary trademarks, logos, product names, etc., have been removed?
- Meets Board policy (including IPR)
Use the above information to create a key project facts section on your project page
Key Project Facts
Project Name:
- JIRA project name: Data Collection Analytics and Events
- JIRA project prefix: dcaegen2
...