It sounds like we do not have any -1s on this, so I'm going to assume we're good to make this change. I have some other things to focus on at the moment, but will try to get this done as time permits. I'll send another email out with details when I go to make the change, and will allow some time before pushing anything in case someone has concerns. -- Thanks, Jeff
On Mon, Jul 17, 2017 at 2:14 PM, Dave Neuman <neu...@apache.org> wrote: > +1 on the rename > > On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <j...@knutsel.com> wrote: > >> +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 >> > > > >> > > >> > >>
