-
Notifications
You must be signed in to change notification settings - Fork 600
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
E2E test for Channel Tracing #1858
Conversation
[APPROVALNOTIFIER] This PR is APPROVED This pull-request has been approved by: Harwayne The full list of commands accepted by this bot can be found here. The pull request process is described here
Needs approval from an approver in each of these files:
Approvers can indicate their approval by writing |
expectedNumSpans := 3 | ||
if tc.incomingTraceId { | ||
expectedNumSpans = 4 | ||
} |
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.
Could you explain why the number of spans is different when the incoming message includes trace Id ?
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.
Added a comment to the code, does it make sense?
test/test_images/logevents/main.go
Outdated
@@ -32,7 +35,10 @@ func handler(event cloudevents.Event) { | |||
} | |||
|
|||
func main() { | |||
c, err := cloudevents.NewDefaultClient() | |||
if err := tracing.SetupStaticPublishing(zap.NewNop().Sugar(), "", tracing.AlwaysSample); err != nil { |
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.
Why both logevents
and sendevents
need to call tracing.SetupStaticPublishing
? Will it bring a duplicate tracing setup ?
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.
Each Pod must setup tracing independently. The only way I am aware of doing it without our container doing the work is with a sidecar like Istio. As this test does not require Istio, we need to setup the tracing ourselves.
In general, we want to test that a trace that started before the request to the Channel is continued through the Channel to the Channel's subscribers. To do that, we need to ensure there is a trace going into the Channel, hence we instrument the sending pod, as well as ensure the same trace is going to the Channel's subscribers, hence we instrument the logging pod.
/test pull-knative-eventing-integration-tests |
/retest |
t.Fatalf("Error getting logs: %v", err) | ||
} | ||
// This is the format that the eventdetails image prints headers. | ||
re := regexp.MustCompile("\nGot Header X-B3-Traceid: ([a-zA-Z0-9]{32})\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.
This is a bit hacky...
We should find a better way to get the header, but can be in a different PR..
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.
Totally agree, what do you recommend?
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.
We can define a library to add and parse headers to/from the logs, each header will be quoted with something like <header>...</header>
. We can also use the similar way to log and parse the body of cloud event, if we need more accurate check on it.
This requires bigger changes, so it can be in a different PR.
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.
#1945 to track.
This is ready for review. |
incomingTraceId bool | ||
istio bool | ||
}{ | ||
//"no incoming trace id": {}, |
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.
Ah, so this one is still not working? :)
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.
Works consistently on my Linux desktop, is flaky on my Mac laptop. For now, I'll leave it commented out (or I could remove the line if you prefer), so that the rest of the test can get in.
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.
Removed it for now, rather than just commenting it out.
for n, tc := range testCases { | ||
loggerPodName := "logger" | ||
t.Run(n, func(t *testing.T) { | ||
channelTestRunner.RunTests(t, common.FeatureBasic, func(st *testing.T, channel 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.
This function needs to be defined as a helper function, if you want it to be ported to eventing-contrib
to test other channel implementations, example https://github.com/knative/eventing/blob/master/test/conformance/helpers/channel_header_single_event_helper.go
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.
Done.
I didn't know, thanks for pointing it out.
…e reused by eventing-contrib.
/lgtm |
Helps with #1765.
Proposed Changes
Release Note