For the APIs, do not expect to change existing APIs. The protocol will NOT be changed in any way that is not backward-compatible. This has not been an issue for us in practice either – the only changes we have done over the last several years is to add annotations, and this does not break compatibility.
Regarding the svc-monitor issue, the API being used there was the UVEs. UVEs and Alarms have no dependency on Cassandra. The UVE API is the most visible and heavily-used feature in Analytics. It provides consolidated Operational State of the system, across all our control/config processes as well as the vRouter agents. This not trivial to implement in a robust and scalable way. We intend to maintain compatibility. From: Valentine Sinitsyn <valentine.sinit...@gmail.com<mailto:valentine.sinit...@gmail.com>> Subject: [opencontrail-dev] [TSC] Analytics and web ui on OC 5.0 and beyond Date: September 21, 2017 at 2:33:17 AM PDT To: "dev@lists.opencontrail.org<mailto:dev@lists.opencontrail.org>" <dev@lists.opencontrail.org<mailto:dev@lists.opencontrail.org>> Cc: krzysztof.klimo...@codilime.com<mailto:krzysztof.klimo...@codilime.com> 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 Dev@lists.opencontrail.org<mailto:Dev@lists.opencontrail.org> https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.opencontrail.org_mailman_listinfo_dev-5Flists.opencontrail.org&d=DwICAg&c=HAkYuh63rsuhr6Scbfh0UjBXeMK-ndb3voDTXcWzoCI&r=CkqqemQs81xoB8oI-8Ct5AJVYlbqW7Pax8WKcQF9bO8&m=5IMKS0jCuXj5p7ZPPTgeKQsOL9sBu4UQBWkUIlCOpkE&s=ReUMP6P1t96GBoAbJooPRsd3qzoU_ZJKwR-DftE-psA&e=
_______________________________________________ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
