Thanks for the proposal. I have a few questions:

1. For 4Q17 R1 ONAP release, there will be VES collector and SNMP TRAP collector, but no batch data collector. Am I right?
2. Would you clarify how does DCAE collect the data from the existing VIM, e.g. ceilometer of OpenStack?

#1 - The VES specification supports batch events; hence that's is already supported in the VES Collector.

#2 - That is handled by separate collector/ms (not part of ONAP currently or in this new project proposal). The collector basically uses restful api provided by ceilometer to collect the stats periodically.

SNMP Trap collector is identified. For underlay/WAN scenarios, more collectors have to be considered:

•  SNMP polling
• Netconf
• and perhaps more.

Time series data base (e.g. influxDB) could be added to the list of potential interesting data bases. 

What is dcaegen2/controller/sch? 

Batch Processing is currently not supported in the VES (evel) agent code. However, the requirements can be found in the requirement documents and DCAE collector does support it. We will add it in the next release.

In VoLTE use case,it needs to collect data of compute nodes, vms and vnfs,these data may include performance, alarm data, etc.I don't know how these data are collected in DCAE whether these different levels of data can be collected by VES Collector.

Does the DCAE provide the GUI function to show the collected data / events, like performance, alarm, fault, etc.?

VES agent currently in ONAP Git is a C Library that can be used by VNF vendors to generate events from their VNFs in VES Format. DCAE collector would be able to receive these events, check for Security and syntax and provide acknowledgement.

An example of this integration can be found in the vFW and vLB, two VNFs in the ONAP. For additional help or questions, please reach out to me. DCAE has lots of sub-components that can be customized by service providers.  I am currently working on PoC/Demo, where we will  be able to support VES 5.0 events: vFW/vLB => DCAE Collector => DMaaP => Influx DB => Grafana Dashboard. We will have the Poc/Demo completed by Mid June, 2017. This frame work could be used for experimenting/building new sub-systems in DCAE.  

I also would like to consider the following JIRA items as part of this proposal if these are not solve earlier:

DCAE-9 - Getting issue details... STATUS

DCAE-5 - Getting issue details... STATUS

DCAE-10 - Getting issue details... STATUS if the following epic is approved COMMON-10 - Deploy automatically an ONAP high availability environment Open

DCAE-6 - Getting issue details... STATUS

DCAE-3 - Getting issue details... STATUS

Some clarifications from questions on the Initial Project Proposal Feedback page.

1. On VES, PNF, and SNMP collectors:
   1. From a platform perspective, the DCAE project is about providing the framework on which to run collectors of any type as well as analytics.  The definition of standard collectors should really be a separate project as things that run on DCAE, but are not part of the DCAE platform itself.
2. Cloud computing...
   1. The DCAE platform itself does not define or care about the events from the cloud platform.  The service assurance flows that run on the DCAE platform do, so again, I believe if standards are being proposed that need to be supported by DCAE, then those should be a separate projects at the application layer, rather than the platform layer.
3. What is the role of cloudify?
   1. The DCAE platform uses cloudify at two different layers.  First, as a "Common Controller Framework" application, the DCAE platform is able to use cloudify to deploy itself.  (e.g. bootstrapping Cloudify, deploying consul, database services, hadoop infrastructure, Docker infrastructure, etc.)  At the application layer (i.e. service assurance flows that run on the DCAE platform), DCAE use Cloudify to deploy and manage service assurance flows when triggered by VNF lifecycle events.

In response to latest comments from the TSC:

1. We might want a portal for DCAE ...
   1. Since DCAE is planned to be built using the Common Controller Framework, it will have a portal where administrators can view the health of the DCAE platform itself as well as services running on the DCAE platform.  The intention, however, is to monitor the health, metrics, etc. of the running components, not the data generated by the analytics modules that run as part of that service.  Since those are all application-specific, the approach we would prefer is for the DCAE analytic to publish its results to DMaaP, and have an external application-specific-portal pick up the results and present a user interface view of the health of the VNF that service is monitoring.

Also in response to TSA comments:

1. regarding subproject priorities: Added description on how we plan to prioritize sub-projects in the project description section of the project proposal;
2. regarding committer responsibilities: Work in progress.  targeting finalizing within a week;
3. regarding OPNFV as external standards body: Updated proposal text;
4. regarding Holmes seed code: Updated proposal text;
5. regarding interface specification: In high level, DCAE's south bound API is the data collection API (e.g. VNF pushes VES data into); north bound API consists of various OAM APIs that the controller exposes.  In addition, there are "east/west" data plane APIs which are generally though the DMaaP message bus.  For example, collectors publish collected data onto message bus; analytics receive them by subscribing to the topics that collectors publish to.  Analytics also publishes analysis results to message bus; and Policy subscribes to these topics to receive alarms.   More detailed description is probably better provided after the projects are decided so that the interfaces between projects can be discussed and specified.
6. regarding demo repo usage: In past experience, deployment and configuration scripts and specifications are managed in a hierarchical fashion.  That is, for example, ONAP system level deployment will call each component's entry script (e.g. A&AI's entry script, DCAE's entry script, etc).  Then each individual component's entry script completes the component's internal deployment and configuration.  This repo is for such purpose, hosting DCAE's own startup scripts, specifications, configurations, etc.  It may be reasonable for the use case repos to host use case specific scripts/configurations, generic per-component (i.e. DCAE) scripts/configurations still need a home.  More over, files in this repo will be reviewed by DCAE committers, who are more familiar with how these files are used.
7. regarding communications with use case definition projects: We have been working with the CLAMP project on defining the data collection and analytics needs for the use cases.  Please advice on what additional bodies that we should work with in this regard;
   
   

For the multi-vim side to expose VIM layer Fcaps and monitoring data, we need to support both agent and agentless data collection in R1. The agentless way will be used to collect data from REST API exposed by multi-vim service.  Considering the tight schedule, it can be VES compitable or discuss adoptes acceptable event format by DCAE.

To document the concerns I raised during the meeting:

• For ONAP Lifecycle Manager, I understand the options you've laid out for integration with ONAP Operations Manager (OOM).  However, I would be concerned about option #2.  I believe it's important that we have one component that is knowledgeable about all the ONAP containers/VMs that have been instantiated.  For the same reason we have A&AI for VNFs, we should have one system that controls & tracks all ONAP components.  DCAE can still determine when it needs new services, but should work with OOM to create those services.
• For Service & config registry, MSB is providing this functionality for the rest of ONAP, and they are also using Consul.  Can you leverage that work, so we are not duplicating efforts?

In VoLTE usecase,the Fcaps and monitoring datas from VNFs and vim layer are needed in R1.In this usecase,it involves the interfaces between DACE and VF-C and the interfaces between DACE and Mutil-vim, so these interfaces are needed in DCAE R1 not the future release.
DCAE should provide south bound REST API which will be used to push relative data to DACE for analysis and Close Loop control by other projects.In addition, the interface data format also needs to be defined in R1.

Lusheng Ji

Is SNMP Collector code going to be opened in this release?

As I understand DCAE currently enables closed loop control and overall service assurance in ONAP. Also seen a rich toolset with VES collector, CDAP, Cloudify orchestration of blueprints etc. I would like to know if there is any capability planned just to visually monitor the alarms or telemetry data as received by the collector ? Is there any plan to create a portal/dashboard or tool set for logging the alarms/metrics and visualizing them.  Currently I guess this is possible only through an analytics application capturing the events from collector and aggregating it to be consumed by a visualization tool.  

I understand that DCAE is subscribed to DMaaP topic to receive A&AI events. We are looking to implement similar functionality via Robot for vCPE use cases.

Could you please share some info where can we see your implementation of DMaaP subscriber module.

Thanks

Geora

Laurentiu Soica:

A demo was completed last June and was demonstrated on OPNFV, Beijing Summit. You can view it on the youtube by searching for VES and ONAP.

Please let me know if you additional questions.

Hello Everyone,

I am facing an issue in DCAE deployment. I am seeing DCAE VMs gets bootstrapped via cloudify. I am facing an issue on the same. Bootup task is failing.

The Designate services are running on the openstack side. But still seeing the issue. Please suggest.

2018-03-14 06:19:56 CFY <local> [floatingip_vm00_a9ef0.create] Task succeeded 'neutron_plugin.floatingip.create'
2018-03-14 06:19:56 CFY <local> [private_net_56b12.create] Task started 'neutron_plugin.network.create'
2018-03-14 06:19:56 LOG <local> [private_net_56b12.create] INFO: Using external resource network: oam_onap_3Ctf
2018-03-14 06:19:56 CFY <local> [private_net_56b12.create] Task succeeded 'neutron_plugin.network.create'
2018-03-14 06:19:57 CFY <local> [key_pair_2c3fe] Configuring node
2018-03-14 06:19:57 CFY <local> [security_group_7561d] Configuring node
2018-03-14 06:19:57 CFY <local> [floatingip_vm00_a9ef0] Configuring node
2018-03-14 06:19:57 CFY <local> [private_net_56b12] Configuring node
2018-03-14 06:19:57 CFY <local> [key_pair_2c3fe] Starting node
2018-03-14 06:19:57 CFY <local> [floatingip_vm00_a9ef0] Starting node
2018-03-14 06:19:57 CFY <local> [security_group_7561d] Starting node
2018-03-14 06:19:57 CFY <local> [private_net_56b12] Starting node
2018-03-14 06:19:58 CFY <local> [dns_vm00_059b8] Creating node
2018-03-14 06:19:58 CFY <local> [dns_cm_e2faf] Creating node
2018-03-14 06:19:58 CFY <local> [dns_cm_e2faf.create] Sending task 'dnsdesig.dns_plugin.aneeded'
2018-03-14 06:19:58 CFY <local> [dns_vm00_059b8.create] Sending task 'dnsdesig.dns_plugin.aneeded'
2018-03-14 06:19:58 CFY <local> [dns_cm_e2faf.create] Task started 'dnsdesig.dns_plugin.aneeded'
2018-03-14 06:19:58 CFY <local> [dns_vm00_059b8.create] Task started 'dnsdesig.dns_plugin.aneeded'
2018-03-14 06:19:58 CFY <local> [dns_cm_e2faf.create] Task failed 'dnsdesig.dns_plugin.aneeded' -> 'dns'
2018-03-14 06:19:58 CFY <local> 'install' workflow execution failed: Workflow failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> 'dns'
Workflow failed: Task failed 'dnsdesig.dns_plugin.aneeded' -> 'dns'

Are SNMP Collector and Mapper available to use in Beijing release?

Rebecca,  Both SNMP Trap collector and Mapper are stretch goals for DCAE Beijing.  As things currently stand, we are very hopeful that both will be done.  Thanks.  Lusheng

Hi,

Is there any document/steps available to build and deploy the dcaegen2 into my local VM ? all platform and service components.