Fix t3c update when fallback occurs #6169
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
rob05c
added
bug
jrushford
approved these changes
Sep 7, 2021
rob05c
force-pushed
the
t3c-fix-fallenback-update
branch
from
258bfc6
to
df2e0b3
Compare
zrhoffman
pushed a commit
that referenced
this pull request
Sep 7, 2021
(cherry picked from commit 96afe89)
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixed t3c-update when a fallback to a previous Traffic Ops API version occurs.
The bug was that when a fallback occurred, the "old" client was doing a Get instead of a Set.
This also adds a log message of exactly the client's latest version and the version being fallen back to, e.g.
INFO: client.go:112: 2021-09-07T19:56:59.82297Z: cache-config Traffic Ops client: 4.0 not supported, falling back to 3.1, which should be helpful in debugging, and in manually testing this fix.No automated tests, unfortunately this can't be reasonably unit-tested since it's the TO request function itself, and the t3c Integration Test Framework doesn't yet have the ability to use multiple TO versions and fall back between them, and that'd be a pretty big feature to add. FWIW I manually tested and verified it's fixed, and sets the update flags in TO appropriately on a TO without the latest major in the client.
Includes changelog.
No docs, no interface change.
Which Traffic Control components are affected by this PR?
What is the best way to verify this PR?
Run t3c-update against a TO without the latest major version in the client, verify flags are set and unset as specified.
If this is a bugfix, which Traffic Control versions contained the bug?
PR submission checklist
[x] This PR has testsexplained above, can't be tested without a significant test framework enhancement