Hi all, Apologies for the delay, and thanks to Rob for submitting PR 1427 to take care of this. I just merged his PR and that means that `traffic_monitor` has been renamed to `traffic_monitor_java` and `traffic_monitor_golang` has been renamed to `traffic_monitor` (thanks Rob!). This means that we are now one step closer to formally retiring the Java version of Traffic Monitor.
Before proposing a vote, I'd like to get a feel for how quickly we can do the formal retirement. We're currently working on 2.1 so that means that we could retire it as early as 2.2. If we want to be more conservative, we could keep both with the renamed structure for 2.2, and remove the Java version in 2.3. This is the direction I'm leaning, though I'd like to hear from interested parties first. Thoughts? -- Thanks, Jeff On Mon, Jul 24, 2017 at 8:23 AM, Jeff Elsloo <els...@apache.org> wrote: > 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 >>> > > > >>> > > >>> > >>>
