+1 On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson <dewr...@gmail.com> wrote:
> 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 <els...@apache.org> 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) > > <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 > > > > > >
