New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Traffic Ops Golang parent.config #3075
Conversation
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
77dac18
to
afd6a37
Compare
Refer to this link for build results (access rights to CI server needed): |
afd6a37
to
c902d45
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good other than those 3 err check spots which Im not sure if they need to be moved higher or not
0def924
to
bef472f
Compare
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
bef472f
to
d6a672d
Compare
Refer to this link for build results (access rights to CI server needed): |
49b3b4c
to
0516d71
Compare
Refer to this link for build results (access rights to CI server needed): |
retest this please |
Refer to this link for build results (access rights to CI server needed): |
0516d71
to
5371a52
Compare
As requested in PR Review.
As requested in PR Review.
Also renames local variables, per PR Review.
Per PR Review.
3130567
to
ce7619b
Compare
@ocket8888 Odd, this PR shouldn't affect those files. I just rebased to the latest master, try now? |
Refer to this link for build results (access rights to CI server needed): |
Builds now. Problem was new files introduced to the repo that were untracked in your branch - caused compilation errors because of docker's recursive copy and go's implicit build system. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I just have a couple of nitpicks and some questions, but after testing against both the default CDN-in-a-Box environment and a dump of production data this seems to work exactly as advertised.
Also, fwiw I think it's perfectly fine to log warnings even where Perl didn't - it doesn't change the logic and everywhere you put the //TODO
it seemed like a good idea to me. Not gonna block on that, but if you wanted to add them in it'd be an improvement imo.
} | ||
textLine += ` max_simple_retries=` + ds.MSOMaxSimpleRetries + ` max_unavailable_server_retries=` + ds.MSOMaxUnavailableServerRetries | ||
} | ||
textLine += "\n" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would it make more sense to instead later join the array with "\n"
instead of doing this every time and joining with an empty string?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe. At this point, I'd really prefer not to change it. These variables are reused so much, as an artifact of Perl, I'd be afraid of accidentally changing the logic and breaking something. I added a TODO so it'll be looked at with the rest of #3515 if that's ok?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
It's not a bug, so I'm fine with it as long as it's captured somehow.
Refer to this link for build results (access rights to CI server needed): |
We need to be mindful of the amount of logging we add and decide whether or not it really needs to be added at all, and if it truly is needed, it should be logged at the right level. If we add unnecessary warnings to code that gets called thousands of times during a Queue Updates operation, then we now have thousands of warnings that could otherwise be drowning out actual problems that need addressed. Basically, if a warning is just "normal operation" of the system, then it should not be logged as a warning. A warning generally means that that the system is operating sub-optimally, and that something needs addressed before the warnings start leading to errors. If someone is digging into the logs, they should be able to quickly identify issues without having to sift through a bunch of meaningless information. A good rule of thumb is to imagine you're the ops engineer that's been tasked with triaging an issue in Production and has to dig into the logs without any knowledge of the code internals. You'll want to do yourself a favor at that point. Just my 2 cents :) |
I agree. As far as I'm aware, all the warnings I added are things that should be addressed. But I could be mistaken, this code in particular is pretty easy to mistake normal operation for an issue, I'm open to changing anything that was misunderstood and acceptable as normal operation. |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
Refer to this link for build results (access rights to CI server needed): |
I think the current warnings in this PR are fine. I don't really know which warnings @ocket8888 was referring to, but from what I can remember about my initial review a long time ago, most of my comments about removing logging were for logs that seemed like informational debug logs that would only be useful for developing/testing this implementation. ¯\_(ツ)_/¯ |
I was referring to logs that aren't there, there are two or three places where data is missing or malformed that just causes the current function to bail or skip the current item and he has e.g. |
Yeah, those particular comments, I'm not sure whether it's normal operation, or an issue |
retest this please |
Refer to this link for build results (access rights to CI server needed): |
I believe all my comments have been addressed so I'm dismissing my review for now
What does this PR do?
Traffic Ops Golang parent.config
Still WIP. I've tested against a single edge and mid; still need to test against a large number of configurations of edges and mids.Removing WIP - I think this is good to be merged. I've manually diffed versus the old Perl parent.config, against every edge and mid in our production CDN.
The only differences vs Perl, are where duplicate origins exist with different configurations (a data bug), and Perl arbitrarily selects one with no warning or error. Go now logs an error when that happens. Unfortunately, Perl is ordering them by an internal Perl hash of the object, which isn't feasible to replicate in Go. But again, it's a data bug to have that scenario at all.
Fixes #3071 in 48ba440
Does not fix #2725 - that's a much more invasive fix, I think should be a separate PR.
Includes API tests.
Which TC components are affected by this PR?
What is the best way to verify this PR?
Check all that apply