Hi, We noticed the new Go Monitor uses two config files and these files are incompatible with the Java implementation. Some config directive's name also changed. Will/should the rpm upgrade be able to take care of the config file conversion/split?
Thanks, -Hongfei -----Original Message----- From: Nir Sopher [mailto:[email protected]] Sent: Monday, October 23, 2017 3:34 PM To: [email protected] Subject: Re: Promote Golang Traffic Monitor to Default 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 <[email protected]> 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 <[email protected]> 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 <[email protected]> wrote: > >> +1 on the rename > >> > >> On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <[email protected]> > wrote: > >> > >>> +1 > >>> > >>> On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson > >>> <[email protected]> > >>> wrote: > >>> > >>> > When: Read · Mon, Jul 17. > >>> > <https://timyo.com/?utm_source=expectationheader&utm_medium=emai > >>> > l> > >>> > [image: Timyo expectation line] > >>> > +1 > >>> > > >>> > On Fri, Jul 14, 2017 at 2:49 PM, Jeff Elsloo <[email protected]> > 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) > >>> > > <[email protected]> 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 > >>> > > >> <[email protected]> > 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 > >>> > > > > >>> > > > >>> > > >>> >
