Hi, What would be the content of 2.2? If we want to have very limited content as suggested in the summit, I would suggest to leave Java TM, removing it only on TC 2.3.
If the 2.2 version has substantial content, I would see leaving the old TM as part of the release as a liability. Old TM should be adjusted to the changes and tested regularly. So in this case, if there are no automated tests to cover its functionality, I would suggest to remove Java TM from the code base. Nir On Mon, Oct 23, 2017 at 5:58 PM, Jeff Elsloo <els...@apache.org> wrote: > 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 > >>> > > > > >>> > > > >>> > > >>> >
