Traffic Monitor Cannot Be Upgraded Independently of Traffic Ops

[rob05c]

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 recommend coordinating with #5006 to fix both in the same release.

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:

[ocket8888]

#4916 possibly fixes this without vendoring by using the latest client and falling back on v2. Is that acceptable?

[zrhoffman]

Should specify which git ref this applies for, as TM currently (1e9b1ed) uses the v2 traffic ops client.

[rob05c]

#4916 possibly fixes this without vendoring by using the latest client and falling back on v2. Is that acceptable?\

If it makes TM work with the previous major version of TO/TC, yeah.

But I'm guessing that's fundamentally incompatible with 4.x. So we'll probably need a specific fix rather than a backport for 4.1.

Should specify which git ref this applies for, as TM currently (1e9b1ed) uses the v2 traffic ops client.

This was observed when upgrading to 4.0.

[ocket8888]

I'm guessing that's fundamentally incompatible with 4.x.

It is. A fix could be made for 4.x with the same basic solution, but in that case it shouldn't be a part of master.

[rawlinp]

Fixed on master and 4.1.x now.