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 <[email protected]<mailto:[email protected]>> 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) < [email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[email protected]>> wrote: +1 on the rename On Mon, Jul 17, 2017 at 10:23 AM, Jan van Doorn <[email protected]<mailto:[email protected]>> wrote: +1 On Mon, Jul 17, 2017 at 9:47 AM Dewayne Richardson <[email protected]<mailto:[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]<mailto:[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]<mailto:[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]<mailto:[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
