I think we can handle the config file differences with a release note for 2.2.0, with a note that the Java version has been officially deprecated and will be retired in the next release. I think that allows people time to get to the new version without being too heavy handed in the project's repo prior to 2.3. -- Thanks, Jeff
On Mon, Oct 23, 2017 at 3:07 PM, Hongfei Zhang (hongfezh) <hongf...@cisco.com> wrote: > thanks. can we document the usage of the new directives then? a simple read > me in configure dir? > > On Oct 23, 2017, at 5:03 PM, Dave Neuman > <neu...@apache.org<mailto:neu...@apache.org>> wrote: > > 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) < > hongf...@cisco.com<mailto:hongf...@cisco.com>> 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:n...@qwilt.com] > Sent: Monday, October 23, 2017 3:34 PM > To: > dev@trafficcontrol.incubator.apache.org<mailto:dev@trafficcontrol.incubator.apache.org> > 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 > <els...@apache.org<mailto: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<mailto: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<mailto:neu...@apache.org>> > wrote: > +1 on the rename > > On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn > <j...@knutsel.com<mailto:j...@knutsel.com>> > wrote: > > +1 > > On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson > <dewr...@gmail.com<mailto:dewr...@gmail.com>> > 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 > <els...@apache.org<mailto: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<mailto: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<mailto: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 > > > > > >
