Hi Pasi, Our suggestion was specifically for VNF Event Streaming (https://wiki.opnfv.org/display/ves/VES+Home) which is one of the options supported as collection mechanism in DCAE. Please refer to the documents shared by Alok here<https://wiki.onap.org/display/DW/VNF+Requirement+validation+for+DCAE> . Regarding your comment on performance – please refer to an evaluation available in public domain here<https://www.slideshare.net/IgorAnishchenko/pb-vs-thrift-vs-avro> which compares Protobuf, Avro and Thrift.
Protobuf can define the schema (VNF originated event format) in a .proto file. Example can be seen here<https://blogs.cisco.com/sp/streaming-telemetry-with-google-protocol-buffers>. Regards Manoj From: onap-discuss-boun...@lists.onap.org [mailto:onap-discuss-boun...@lists.onap.org] On Behalf Of Pasi Vaananen Sent: Friday, July 14, 2017 6:51 PM To: onap-discuss@lists.onap.org Subject: Re: [onap-discuss] [dcae] Google Protocol Buffer support for VES [External Email] ________________________________ Hi Manoj, Is your proposal in any way aligned with what has been proposed on openconfig<http://www.openconfig.net/> streaming telemetry project, or would this be an independent ONAP specific version built around the gRPC ? Would this be used just for the VNF originated events/metrics, or also for the infrastructure originated events/metrics ? Would you tie the descriptions of VNF originated events to some way to describe what VNF is able to expose as part of the VNF package (either tied to TOSCA or some other way) ? We have been testing the capabilities of Kafka vs. AMQP (using Apache QPID dispatch router<https://qpid.apache.org/components/dispatch-router/index.html>) with the very specific goal to assess delivery capabilities of low-latency events (targeting fault events that need "fast", sub-50ms remediation processes) along with large amounts of metrics data in the same messaging "bus". We have not tested either VES or gRPC performance, but binary encoding could also help on the events side, as it could eliminate the unnecessary encoding/parsing steps from the path (obviously assuming that the event syntax, semantics and context data are well defined in the first place). Thanks, Pasi Vaananen, Systems Architect, NFV Office of Technology, Red Hat On 07/14/2017 05:01 AM, Manoj K Nair wrote: Hi Alok, We reviewed the VES specification you shared after the presentation in DCAE weekly meeting couple of weeks back. We understand that currently VES supports a REST based interface with JSON payload to push telemetry data and events from the VNF to DCAE VES collector. For telemetry control an HTTP response channel is being used as per the test code link you published in the presentation. Just wondering if GPB is considered as one of potential options for VES. You have noted the use of Avro as one potential option as future enhancement. Wondering if GPB is also a potential option you are considering. Some of the advantages we see for GPB are. • Uses binary formatting during serialization, which densily packs the payload (which is good for PM/telemetry data) • Faster than the VES proposed JSON payload (which is good for events and alarms) • Can define the structure (schema) of events/telemetry data in a protocol definition file (.proto) which is similar to the JSON schema that is available in OPNFV VES project • Availability of code generators in multiple programming languages for encoding and decoding - Can generate code in C#, C++, Java, Python, Go . Options in other languages available as well. While we have noted the dynamic schema capabilities in Avro, one key advantage we see with GPB is the serialization code generation in multiple languages without limiting to the C language based library which is currently available and open source tool sets available for GPB. Moreover many network vendors and open source monitoring solutions (e.g. Prometheus, link<https://prometheus.io/docs/instrumenting/exposition_formats/>) support GPB already. We would be glad to share more information on the potential GPB usage if required. Regards Manoj [https://www.netcracker.com/assets/img/netcracker-social-final.png]ƕ ________________________________ The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer. _______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org<mailto:onap-discuss@lists.onap.org> https://lists.onap.org/mailman/listinfo/onap-discuss ________________________________ The information transmitted herein is intended only for the person or entity to which it is addressed and may contain confidential, proprietary and/or privileged material. Any review, retransmission, dissemination or other use of, or taking of any action in reliance upon, this information by persons or entities other than the intended recipient is prohibited. If you received this in error, please contact the sender and delete the material from any computer.
_______________________________________________ onap-discuss mailing list onap-discuss@lists.onap.org https://lists.onap.org/mailman/listinfo/onap-discuss
![https://www.netcracker.com/assets/img/netcracker-social-final.png]ƕ](https://www.netcracker.com/assets/img/netcracker-social-final.png]ƕ){kind=link}