fix(source): debug log on gateway target detection

[drcapulet]

This code referenced the endpoints variable which was updated with each resource leading to confusing debug messages - this sets up a new array each iteration to log just the records from the relevant Gateway resource.

[k8s-ci-robot]

Welcome @drcapulet!

It looks like this is your first PR to kubernetes-sigs/external-dns 🎉. Please refer to our pull request process documentation to help your PR have a smooth ride to approval.

You will be prompted by a bot to use commands during the review process. Do not be afraid to follow the prompts! It is okay to experiment. Here is the bot commands documentation.

You can also check if kubernetes-sigs/external-dns has its own contribution guidelines.

You may want to refer to our testing guide if you run into trouble with your tests not passing.

If you are having difficulty getting your pull request seen, please follow the recommended escalation practices. Also, for tips and tricks in the contribution process you may want to read the Kubernetes contributor cheat sheet. We want to make sure your contribution gets all the attention it needs!

Thank you, and welcome to Kubernetes. 😃

[k8s-ci-robot]

Hi @drcapulet. Thanks for your PR.

I'm waiting for a kubernetes-sigs member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

Once the patch is verified, the new status will be reflected by the ok-to-test label.

I understand the commands that are listed here.

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-sigs/prow repository.

[ivankatliarchuk]

/ok-to-test

[ivankatliarchuk]

As you would like to enchance/improve logging, could you add a test for that?
You could use this method

external-dns/internal/testutils/log.go

Line 36 in ba98af8

func LogsToBuffer(level log.Level, t *testing.T) *bytes.Buffer {

and example usage

external-dns/provider/aws/aws_fixtures_test.go

Line 73 in ba98af8

b := testutils.LogsToBuffer(log.DebugLevel, t)

[mloiseleur]

/retitle fix(source): debug log on gateway target detection

[drcapulet]

@ivankatliarchuk Added tests inside source/gateway_httproute_test.go - appreciate the pointers for log capture. I removed the t.Parallel() call given the log capture helper does not seem to be okay with parallelization.

@mloiseleur Updated the commit message to match yours.

[ivankatliarchuk]

Interesting, I did some digging, and most likely I could explain in a bit more detail what happens

From Go docs https://pkg.go.dev/testing@master#T

logs are accumulated during execution and dumped to standard output when done.

So log output is not emitted immediately to buffer. These are tests running in parallel, and their output is arriving as it happens rather than buffered and presented in-order at the end. That seems to be working as intended.

Where the challange with t.Parallel() is that all parallel tests share the same global logger state (log.SetOutput(buf), log.SetLevel(level), klog.SetOutput(buf)). This means that multiple tests running in parallel may overwrite the logging configuration and buffer, leading to unpredictable results.

Here is some interesting reading about the problem, appreciate may not have time for that

• https://brandur.org/t-parallel
• https://bryce.is/writing/code/go-test-and-parallelism

Shell we run tests in parallel by default, and run sequentially if we would like to test logging ? Something like

if len(tt.logExpectations) == 0 { t.Paralel }

Or we could tweak as well actual helper, to isolate logging output for each tests. One way to achieve this is by using a mutex to synchronize access to the log output.

``go
var mu sync.Mutex

func LogsToBuffer()...
t.Helper()
// Synchronize access to the log output
mu.Lock()
defer mu.Unlock()
...
return ....
}

[ivankatliarchuk]

#5096 (comment)

[ivankatliarchuk]

fixed

[drcapulet]

@ivankatliarchuk Updated to use if len(tt.logExpectations) == 0 { t.Parallel() } since I dug into the t.Run docs it appears we can use t.Parallel() safely.

[ivankatliarchuk]

/lgtm

cc @mloiseleur

[mloiseleur]

We are doing progress here, thanks 👍
/approve

[k8s-ci-robot]

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: ivankatliarchuk, mloiseleur

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:

• OWNERS [mloiseleur]

Approvers can indicate their approval by writing /approve in a comment
Approvers can cancel approval by writing /approve cancel in a comment