Set user-agent per test in e2e framework

[hh]

In order to identify which e2e test is hitting a specific API endpoint

Given an e2e test using e2e/framework/utils
When the user agent is set via client-go config
Then we will be able to log which e2e test called a specific API

Prior discussion: https://groups.google.com/d/msg/kubernetes-sig-api-machinery/R-z_NjiLzmg/q1kWg9jSAQAJ

/kind feature
/cc @kubernetes/api-reviewers @kubernetes/sig-testing-feature-requests @liggitt @lavalamp @bgrant0607

[hzxuzhonghu]

If we want to only set User-Agent in a common place, 　I think add config.UserAgent = f.BaseName here can work well.

kubernetes/test/e2e/framework/framework.go

Lines 154 to 157 in fd044d1

	config, err := LoadConfig()
	Expect(err).NotTo(HaveOccurred())
	config.QPS = f.Options.ClientQPS
	config.Burst = f.Options.ClientBurst

[hzxuzhonghu]

cc @sttts @tallclair @CaoShuFeng

[sttts]

@hzxuzhonghu had the same thought.

[rohfle]

Since User-Agent is a HTTP header itself, would it be better to create descriptive headers specifically and then log all headers in audit logs?

Something like:

GET / HTTP/1.1
Host: kubernetes.master
User-Agent: curl/7.58.0
Accept: */*
Kubetest-Name: "[storage] storage related tests"
Kubetest-Description: "should do the thing"
Kubetest-File: "path/to/test.go:43"
...
HTTP/1.1 200 OK

[tallclair]

For the sake of argument, alternative approaches that wouldn't require changes to auditing:

• Append a custom query string, which would generally be ignored but show up in the audit log URL field
• Act as a per-test service account. Requires creating the account & RBAC bindings.

However, since we want to add user-agent to the audit logs anyway, I agree that's the preferred approach.

[hh]

What about generically add support in kubernetes/client-go to set user-agent to the calling src code file and line using runtime.Caller.

An off-by-default option, having this level of insight for any k8s application seems like an easy win. Generating an index of test data that includes links to github for all calling/called functions.

I'm exploring this idea a bit further: https://github.com/cncf/apisnoop/issues/23

[fejta-bot]

Issues go stale after 90d of inactivity.
Mark the issue as fresh with /remove-lifecycle stale.
Stale issues rot after an additional 30d of inactivity and eventually close.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle stale

[fejta-bot]

Stale issues rot after 30d of inactivity.
Mark the issue as fresh with /remove-lifecycle rotten.
Rotten issues close after an additional 30d of inactivity.

If this issue is safe to close now please do so with /close.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/lifecycle rotten

[fejta-bot]

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

[k8s-ci-robot]

@fejta-bot: Closing this issue.

In response to this:

Rotten issues close after 30d of inactivity.
Reopen the issue with /reopen.
Mark the issue as fresh with /remove-lifecycle rotten.

Send feedback to sig-testing, kubernetes/test-infra and/or fejta.
/close

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository.