#opendaylight-meeting: tws

Meeting summary

1. SDN SDK Presentation (tbachman, 17:01:50)
   1. The SDN SDK group had a creation review, and the TSC had a lot of questions around the project’s scope. This TWS was meant to provide a forum to allow the SDN SDK group to better address/present the scope of their project (tbachman, 17:06:01)
   2. The focus of the Centinal project is only for the logging functionality of ODL (tbachman, 17:06:47)
   3. The ODL logging mechanism is very expensive — multiple logs generated from various ODL features, modules, and tools (tbachman, 17:07:17)
   4. Engineers are expected to have ODL know-how to figure out seach queries in logs to extract intelligent data (tbachman, 17:07:36)
   5. The isn’t a real-time tracking of logs (per user defined rules) for specific error conditions or diagnosis (tbachman, 17:07:59)
   6. expcetation of a classid monitoring user-interface to track set rules/threshold alerts log/data (tbachman, 17:08:30)
   7. The project uses the MD-SAL, Log source, DB/Presistence, cassandra/Hbase from ODL (tbachman, 17:10:08)
   8. it Adds a web interface with dashboard, alerts, streams, log search and analytics, diagnostics, and health (tbachman, 17:10:37)
   9. There will also be NB APIs (tbachman, 17:10:51)
   10. Prem_ has submitted a similar topic for the ODL summit, and is interested in possibly collaborating with this effort (tbachman, 17:11:31)
   11. Prem_ proposal includes a log analyzer in order to correlate logs between various modules as a first step (tbachman, 17:12:02)
   12. dbainbri asks why a standard off-the-shelf library/tools (e.g. ELK) insn’t used instead (tbachman, 17:12:32)
   13. Prem_ says that for their proposal is to use the log stack for available analyzers (tbachman, 17:12:51)
   14. sumit_kapoor says they’re doing more analysis and features that aren’t provided by current analyzers — things that are ODL specific (tbachman, 17:13:20)
   15. dbainbri asks if they’re driving all logs through the MD-SAL (tbachman, 17:13:55)
   16. sumit_kapoor says only the rules are going into the ODL data store (tbachman, 17:14:17)
   17. dbainbri says sounds more like an analyzer (tbachman, 17:15:34)
   18. dbainbri asks if he has to update his log4j code to support this (tbachman, 17:17:36)
   19. sumit_kapoor says you don’t have to update your code (tbachman, 17:17:46)
   20. sumit_kapoor says there’s a syslog appender that sends the messages in real time to their syslog (tbachman, 17:18:45)
   21. sumit_kapoor says they offer more analytics/diagnostics before persisting (tbachman, 17:19:27)
   22. dbainbri says he sees two different things — log collection and real-time analytics and batch processing (e.g. SPARK), and wouldn’t want the MD-SAL in the way of eitehr of those (tbachman, 17:21:05)
   23. sumit_kapoor says this is a framework for the performance data as well. (tbachman, 17:23:50)
   24. dbainbri is concerned about multiple projects going after the same capability (tbachman, 17:25:21)
   25. moizer asks if they’ve considered using Flume + Kibana for the same purpose? (tbachman, 17:29:17)
   26. Prem_ says their presentation would be around that (tbachman, 17:32:02)
   27. dbainbri says right now he’s less concerned about technology and more concerned about a common philosophy about stream processing (tbachman, 17:32:30)
   28. dbainbri also includes a common direction in batch processing as well. (dbainbri, 17:32:51)
   29. The project provides a streams service, which has a mechanism to route messages into categories in real time while they are processed like stream for audit logs; rule configuration include message, level, source, etc.; streams are generated by the graylog server as per user-defined rules; event handler module handles streams from graylog server and persist them into centinel model (tbachman, 17:35:26)
   30. Log alerts service allows alerts generated based on specific event matching in real-time; alert condition types can be message count, field value, and field string value (tbachman, 17:36:00)
   31. Search and Analyze service supports a search query language; a time range for search can be specified; visualization includes histogram (tbachman, 17:36:40)
   32. Prem_ asks dbainbri if a unified log analyzer that analyzes SDN Apps + ODL + SDN switch would be beneficial? (tbachman, 17:40:09)
   33. dbainbri asks how log analysis is different from analyzing any other data stream — argues that it isn’t, so that ODL needs a way to analyze stream data and combine data from multiple sources in that analysis (tbachman, 17:42:31)
   34. dbainbri says this normalizes log data (as well as other data) in some way, and then people can write different analytics against the data (tbachman, 17:43:01)
   35. dbainbri thinks log data is just yet another event (dbainbri, 17:43:10)
   36. dbainbri also thinks ODL logs are often clogged with "system or debug" logs as opposed to messages that mean something from the "control" aspect. (dbainbri, 17:43:51)
   37. dbainbri continues to think that this means not all logs have to end in a generated event that needs to be analyzed . (dbainbri, 17:44:23)
   38. Prem_ agrees it does become another stream of data provided it is processed and normalized (tbachman, 17:44:30)
   39. alagalah asks if there’s a new project proposal for Centinel? (tbachman, 17:44:47)
   40. sumit_kapoor says this is a new project proposal — it’s one of the features of the original SDN SDK proposal (tbachman, 17:45:08)
   41. alagalah asks if they’re using the persistence project — not introducing a new dependency on the data store (tbachman, 17:46:07)
   42. sumit_kapoor says they’re using the persistence project (tbachman, 17:46:14)
   43. dbainbri asks if alarms are going through the persistence layer (tbachman, 17:46:47)
   44. sumit_kapoor says yes (tbachman, 17:47:01)
   45. dbainbri asks if the ODL persistence project is capable of handling an alarm storm? (tbachman, 17:47:47)
   46. sumit_kapoor says if these things happen, the alarm storm would be handled before persisting (tbachman, 17:48:08)
   47. colindixon asks if the project decomposes into 3 pieces; log gathering; log analysis framework; analysis programs (tbachman, 17:52:12)
   48. colindixon says it’s more work to create rules that make meaningful alarms than it is to create a rules engine — asks if they will be contributing rules themselves (tbachman, 17:54:12)
   49. sumit_kapoor says they will specify some preconfigured rules — e.g. for the openflowplugin (tbachman, 17:54:26)
   50. sumit_kapoor says ODL users can creat emore rules (tbachman, 17:54:42)
   51. Prem_ asks if the rules can be derived from the state diagrams of any apps/module? (tbachman, 17:54:56)
   52. sumit_kapoor says they will also provide some preconfigured rules for SFC (tbachman, 17:55:12)
   53. dbainbri: need to separate technology from common best practice philosophy (dbainbri, 18:04:26)

Action items

1. (none)

People present (lines said)

1. tbachman (62)
2. dbainbri (18)
3. odl_meetbot (6)
4. Prem_ (6)
5. abhijitkumbhare (3)
6. icbts (2)
7. alagalah (2)
8. colindixon (1)
9. sumit_kapoor (1)