For the most part, it's a drop in replacement for the Java version, and based on our own experience it seems to work exactly as the Java version would, including co-existence. There is a TO API dependency for monitoring.json that the Java version does not have, and I'm not sure what the history is with that endpoint and how far back we could remain compatible. Traffic Router does not care what version of Traffic Monitor it talks to, as the format of cr-states.json has not changed. Same goes for TM and ATS. I believe we had co-existence running in production going back to the 1.8.x releases.
Keep in mind that the intent is to drive users toward using the Golang component by default starting with the 2.1.0 (or maybe 2.2.0?) release while still allowing one to build, run, or contribute to the Java version until our next major release (3.0.0). The intent is not to give people a drop in replacement that works with prior versions; we have not tested that thoroughly across all versions, and while it might work, we should think of the Golang Traffic Monitor as a 2.0.x and onward component. I think that statement holds for most of our components; we wouldn't want to run a 1.7 Traffic Stats with a 2.0.0 Traffic Ops system. 1.7 is ancient, and have we ever really done backward compatibility testing with versions? To this end, if we do decide to make the Golang version the default in the future, at a minimum we will need to provide release notes that explain how to convert the Java configuration to the Golang version's config. Ideally we would provide a simple script to convert the configuration for our users, potentially running it as a postinstall scriptlet in the RPM if the Java version is already installed. Theoretically we could `yum upgrade traffic_monitor` and seamlessly move from Java to Golang. -- Thanks, Jeff On Fri, Jul 14, 2017 at 2:07 PM, Eric Friedrich (efriedri) <efrie...@cisco.com> wrote: > I think I remember Rob making this point in Miami, but all of TMs APIs (REST, > CRConfig, Health.json, etc…) are identical between the Java and Golang > version, right? > > What about compatibility with earlier versions of TC? > > For example: > - Can a TC1.7 traffic ops configure a Golang TM? > - Does the Golang TM have any dependencies on a certain version of > TrafficServer or astats? > - Whats the minimum required version of Traffic Router to use the Golang TM? > - I know Golang TMs can gossip with Java TMs, but can we mix versions here > too? (i.e. TC1.7 Java TM with TC2.1 Golang TM)? > > —Eric > > >> On Jul 14, 2017, at 1:00 PM, Jeff Elsloo <els...@apache.org> wrote: >> >> Hi all, >> >> We currently have two versions of Traffic Monitor: Java and golang. >> When we build all components, as far as I know, it results in a race >> condition between the two, as the resulting RPMs have the same >> filename. A PR[1] was opened to address the issue and the approach was >> to add `_go` to the version string used for the golang version's RPM. >> >> Rob and I both think we (Comcast) have enough experience running the >> golang version that we have identified and corrected any major issues >> and that it is stable enough to be the preferred Traffic Monitor hence >> forth. >> >> Therefore, I propose that within the project's directory structure, we: >> 1) rename traffic_monitor to traffic_monitor_legacy >> 2) rename traffic_monitor_golang to traffic_monitor >> >> ..then work with the person that submitted the PR to take the same >> approach, except change the Java version's RPM name to contain >> `_legacy`. >> >> I realize that this is a fairly significant change, the type that we >> typically reserve for major releases. The next major release, 3.0.0, >> is likely to be some time out in the future, and I don't know that we >> need to wait for it in order to make this change. >> >> How does the group feel about the above proposal, and executing on it >> prior to the 3.0.0 release (i.e.: for 2.1.0)? Then, when we do >> actually prepare the 3.0.0 release, we can remove the Java version >> from the codebase entirely. Obviously this could impact anyone that >> has automated CI systems building components, in addition to the >> Apache CI we use ourselves. >> >> Thoughts? >> >> [1] https://github.com/apache/incubator-trafficcontrol/pull/731 >> -- >> Thanks, >> Jeff >
