rob05c opened a new issue #5005: URL: https://github.com/apache/trafficcontrol/issues/5005
Traffic Monitor uses the unvendored Traffic Ops client. This means if the TO API version changes, the client automatically uses the latest, and TM will fail to connect to TO if TM is upgraded first. ATC supports upgrading in any order, which is very frequently necessary for innumerable reasons. So, this is a bug. It's been a bug for a while, but it most recently came up because of another bug in 4.0.x, which being able to upgrade TM first would have worked around. We should fix this by vendoring the client, using the new client and falling back if any new data is necessary (like ORT does, see https://github.com/apache/trafficcontrol/tree/master/traffic_ops_ort/atstccfg/toreq and https://github.com/apache/trafficcontrol/tree/master/traffic_ops_ort/atstccfg/toreqnew). This should be fixed in `master` and backported to 4.1.x and a new 4.1.1 Release made with the fix. ## I'm submitting a ... - bug report ## Traffic Control components affected ... - Traffic Monitor ## Current behavior: Traffic Monitor can not be upgraded independently of Traffic Ops, arbitrarily depending on the ATC version and whether the API was changed. ## Expected / new behavior: Traffic Monitor can be upgraded before or after Traffic Ops, as necessary. ## Minimal reproduction of the problem with instructions: Upgrade Traffic Monitor from 3.0 to 4.0 before upgrading Traffic Ops 3.0, observe failure to connect. ## Anything else: ---------------------------------------------------------------- This is an automated message from the Apache Git Service. To respond to the message, please log on to GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: [email protected]
