I don't think the rpm upgrade will take care of this for you. This will be a one-time manual upgrade.
On Mon, Oct 23, 2017 at 2:59 PM, Hongfei Zhang (hongfezh) < [email protected]> wrote: > 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 > > >>> > > > > > >>> > > > > >>> > > > >>> > > >
