When: Read · Mon, Jul 17. <https://timyo.com/?utm_source=expectationheader&utm_medium=email> [image: Timyo expectation line] +1
On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <[email protected]> wrote: > 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) > <[email protected]> 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 <[email protected]> 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 > > >
