1. Contrail analytics is sigle repository of all the operational state of the system. Think of analytics API as “show commands on the router” Over a period with different requirements from customers, this design has evolved and may have become complicated. Many operators want streaming API for operational state. Evil with analytics has been the cassandra DB. Analytics (my be misnomer) has always been integral part of contrail.
2.I wanted to fix this by separating out the operational state and historical data. May be that is the way to go. 3. Any system new decisions are made based on current operational state. Today service monitor places work bases simple liveliness and random scheduler. Idea wa no make this algorithm more intelligent with more data. Or even customizable. 4. If you threw away analytics, you will end up writing similar logic for operational state of the system. Don’t throw baby with bathwater.Think simplifying and keeping the UVE part. 5. If juniper makes something proprietary then it is their problem to keep compatibility as the data is coming or consumed by open source components. Regards -Harshad > On Sep 21, 2017, at 7:23 AM, Valentine Sinitsyn > <valentine.sinit...@gmail.com> wrote: > > Hi Robert, > > On 21.09.2017 19:13, Van Leeuwen, Robert wrote: >>> 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) >> Might be going a little bit off-topic here but the choice to depend services >> on “analytics data” IMHO is not a good one. >> Contrail-controller knows which vrouters are alive and should be the source >> of truth for anything critical. > I agree here. The point was there are some places in OC which do this > currently, and they should be fixed somehow. Put it another way, we shouldn't > expect that switching off analytics affects analytics only. > > Valentine > >> Using a service that has a very indirect knowledge about the aliveness of >> vrouters feels very bad to me. >> e.g. the node-manager is pushing data about the aliveness that goes through >> a collector, kafka and eventually cassandra. (might not be exactly like this >> but you get the idea) >> Now you are going to base decisions on that info via contrail-api getting >> that from cassandra. >> A hiccup in any of those systems and bad stuff happens. >> E.g we have seen stuff break because analytics was having issues. >> There are some bug fixes for that now but e.g. seeing all load-balancer >> instances removed because analytics is giving faulty or no results makes you >> very sad. >> TLDR: If this would mean there are no longer any dependencies on analytics >> that would make me very happy. >> Cheers, >> Robert > > _______________________________________________ > Dev mailing list > Dev@lists.opencontrail.org > http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org _______________________________________________ Dev mailing list Dev@lists.opencontrail.org http://lists.opencontrail.org/mailman/listinfo/dev_lists.opencontrail.org
