-
Notifications
You must be signed in to change notification settings - Fork 7
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
Add hopannotation1 to paris traceroute #1047
Conversation
Pull Request Test Coverage Report for Build 7149
💛 - Coveralls |
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.
Thank you for these changes.
I think the paris1 hopid construction is incorrect, please see the linked doc.
If the filename timestamp is all we have, then that's the right thing. These paris1 hopids only needs the date portion.
Reviewable status: 1 change requests, 0 of 1 approvals obtained (waiting on @cristinaleonr)
parser/pt.go, line 404 at r2 (raw file):
} // For hopannotation1 hopIDs, the formatting convention is // Timestamp_IP_Hostname. However, the Hops initialized above
This description does not match my understanding from the TRC hopid convention. Can you confirm?
parser/pt.go, line 409 at r2 (raw file):
// The same convention will have to be adopted in the paris1 // parser, so its hops can be joined with the synthetic ones. hopID := GetHopID(float64(logTime.UTC().Unix()), source.IP, source.IP)
source.IP
, source.IP
does not look correct, please see comment below.
parser/pt.go, line 425 at r2 (raw file):
Hostname: allNodes[i].parent_hostname, } hopID := GetHopID(float64(logTime.UTC().Unix()), source.Hostname, source.IP)
Are these the correct three fields composing the hop id from traceroute-caller?
https://docs.google.com/document/d/1VD5t4zRFlYsq_CAH6oCfjynKaEDnpwHnnFbk2mL7_yI/edit?resourcekey=0-NpaXaG91iS8nb02o9fqgbQ#heading=h.mzu1y33z63fh
Also, FYI: @SaiedKazemi (I don't want to miss anything)
parser/pt_test.go, line 367 at r2 (raw file):
Hostname: "sr05-te1-8.nuq04.net.google.com", HopAnnotation1: &hopannotation.HopAnnotation1{ ID: "20170320_sr05-te1-8.nuq04.net.google.com_64.233.174.109",
Please confirm the hop id is correct.
parser/pt.go, line 425 at r2 (raw file): Previously, stephen-soltesz (Stephen Soltesz) wrote…
Looks good to me. Here's what the doc says:
|
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.
Reviewable status: 1 change requests, 0 of 1 approvals obtained (waiting on @cristinaleonr and @SaiedKazemi)
parser/pt.go, line 425 at r2 (raw file):
Previously, SaiedKazemi (Saied Kazemi) wrote…
Looks good to me. Here's what the doc says:
The hop annotation file name should consist of the following three fields concatenated with an underscore character (_) and followed by a .json suffix: 1. Timestamp - This should be the timestamp when traceroute ran (see Hop Annotation File Content for more details). 2. Hostname - This should be the hostname where TRC is running on. 3. IP address - This should be the IP address of the hop that is annotated.
@SaiedKazemi should the Hostname
be that of the M-Lab server or the reverse-lookup hostname of the hop router? Which is being used here?
parser/pt.go, line 425 at r2 (raw file): Previously, stephen-soltesz (Stephen Soltesz) wrote…
@stephen-soltesz Per our offline conversation, the hostname in the screenshot |
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.
Updated the hopid to use the M-Lab server's Hostname
.
Reviewable status: 1 change requests, 0 of 1 approvals obtained (waiting on @cristinaleonr)
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.
Thank you - I think it can be a little simpler. PTAL?
Reviewed 1 of 1 files at r5.
Reviewable status: 1 change requests, 0 of 1 approvals obtained (waiting on @cristinaleonr)
etl/globals.go, line 206 at r5 (raw file):
// For example, for 20170129T000000Z-mlab1-lax05-paris-traceroute-0000.tgz, // it returns mlab1-lax05. func GetHostname(rawFilename string) string {
I think we can eliminate this in favor of using the result already available from etl.ValidateTestPath
in the pt parser.
parser/pt.go, line 925 at r5 (raw file):
} hostname := etl.GetHostname(fileName)
Since the dual use of "hostname" was the source of some of the ambiguity, what do you think of calling this the "machine" throughout instead?
parser/pt.go, line 925 at r5 (raw file):
} hostname := etl.GetHostname(fileName)
Rather than reparsing the archive url, consider reusing the DataPath
type returned by etl.ValidateTestPath
from the logic where Parse()
is called.
The DataPath type has fields for the "Host" and "Site" which together create the machine name.
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.
Updated, thanks!
Reviewable status: 1 change requests, 0 of 1 approvals obtained (waiting on @cristinaleonr and @stephen-soltesz)
parser/pt.go, line 925 at r5 (raw file):
Previously, stephen-soltesz (Stephen Soltesz) wrote…
Since the dual use of "hostname" was the source of some of the ambiguity, what do you think of calling this the "machine" throughout instead?
Done.
parser/pt.go, line 925 at r5 (raw file):
Previously, stephen-soltesz (Stephen Soltesz) wrote…
Rather than reparsing the archive url, consider reusing the
DataPath
type returned byetl.ValidateTestPath
from the logic whereParse()
is called.The DataPath type has fields for the "Host" and "Site" which together create the machine name.
Done.
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.
Bonus points for updating the screenshot. (and thank you! -- it can be very confusing looking back and PRs when the original description becomes out of sync with what was actually done).
Just to confirm, the HopAnnotations1 are now being populated? Is it the case that previously that PTTest.AnnotateHops()
wasn't filling them in b/c the structs were nil
?
I think this will lgtm with confirmation.
Reviewed 2 of 3 files at r6, 1 of 2 files at r7, all commit messages.
Reviewable status: 1 change requests, 0 of 1 approvals obtained (waiting on @cristinaleonr)
parser/pt.go, line 403 at r7 (raw file):
IP: server_IP, } hopID := GetHopID(float64(logTime.UTC().Unix()), machine, source.IP)
These lines look identical here and below.
Is it possible/preferable to eliminate the redundancy?
Code quote:
hopID := GetHopID(float64(logTime.UTC().Unix()), machine, source.IP)
source.HopAnnotation1 = &hopannotation.HopAnnotation1{
ID: hopID,
Timestamp: logTime,
}
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.
Yes, the HopAnnotations
are being populated for paris-traceroute
now. And yes, before they weren't before the structs were nil
for pt.
Reviewable status: 1 change requests, 0 of 1 approvals obtained (waiting on @stephen-soltesz)
parser/pt.go, line 403 at r7 (raw file):
Previously, stephen-soltesz (Stephen Soltesz) wrote…
These lines look identical here and below.
Is it possible/preferable to eliminate the redundancy?
Done.
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.
This - thank you.. DO NOT MERGE YET.
I setup a time for you, @robertodauria and I to talk tomorrow morning (hopefully) to sort out the order of events necessary to minimize headache for getting this into production without breaking anything else and setting us up for decoupling the v1/v2 deployments.
Reviewable status:
complete! 1 of 1 approvals obtained
Part of #1050 |
Notes regarding hop annotations for paris traceroute:
We're using the
LogTime
as the timestamp in theID
and for theTimestamp
field itself. This is the only timestamp that I see in the .paris files and it comes from the filename.I'm not sure if this is equivalent to the
CycleStartTime
we adopted as a convention forhopannotation1
's timestamp.Example hop IP, hostname, and ID:
![Screenshot 2022-02-02 7 51 31 AM](https://user-images.githubusercontent.com/21001496/152157690-eddbf523-2dd6-472d-9b92-3e962f23120a.png)
This change is![Reviewable](https://camo.githubusercontent.com/23b05f5fb48215c989e92cc44cf6512512d083132bd3daf689867c8d9d386888/68747470733a2f2f72657669657761626c652e696f2f7265766965775f627574746f6e2e737667)