Valentine, You have raised some really good points. Analytics is critical and making sure we have a clear road-map is essential. Let's brainstorm on one of the upcoming calls and we should be able to flesh it out together.
Regards, Nabeel -----Original Message----- From: Dev [mailto:[email protected]] On Behalf Of Valentine Sinitsyn Sent: Thursday, September 21, 2017 5:33 AM To: [email protected] Cc: [email protected] Subject: [opencontrail-dev] [TSC] Analytics and web ui on OC 5.0 and beyond Hi all, On the yesterday's OpenContrail Summit, it was announced that Juniper will move for proprietary advanced analytics and web ui in CC 5.0+. Current contrail-analytics and contrail-web-ui will remain open, yet their development will be a purely community-based effort. After having some private discussions, I feel that this change is in TSC scope and suggest adding it to the agenda for our next meetings (not necessarily the very next one, of course). The concerns so far are as follows: 1. API diversion As proprietary web ui and analytics develop, an incompatible changes to the existing APIs (such as contrail-collector protocol) could be introduced. This should be avoided. Given the intention to have OC split into subprojects, we would need a stable, versioned API to cross subproject boundaries, regardless the project is open-source or part of CC only. 2. Telemetry is not analytics Currently all services report their runtime state via Sandesh messages, and analytics basically infers something from this data. While an actual data processing is a great enterprise feature, data collection is more of a commodity which should be kept in the open core. Ideally, we want OC to be able to pump its telemetry into the system of the user's choice using well-defined protocol. So this is perhaps a variation of #1. 3. Hidden dependencies on analytics in OC AFAIK, svc-monitor relies (or used to rely) on analytics data to learn which vRouters are live and able to receive a service instance. Chances are, there are other places like this in the code. If we make analytics pluggable, we must be careful not to break these. SI v1 API has been deprecated for some time, so it's probably as good moment as any to start discussing how to get rid of it (which means we need to figure out SNAT, LB and other "base" services that make use of the fact that contrail can spawn processes/VMs/containers by itself) 4. Frank discussion about current state of WebUI and where we really want to go with it Please speak your minds. Best, Valentine _______________________________________________ Dev mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org _______________________________________________ Dev mailing list [email protected] http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
