+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 > > > > > > > > > >
