Skip to content

Conversation

jvilhuber
Copy link
Contributor

Description:
Fixes the problem where a dns-resolver is defined without a Port element. This SHOULD result in the default port (4317) being used, but leads to some problems. See linked issue.

The gist of the fix is to ensure that the strings in the lb.exporters map always have the port, and are always looked up with the port. Some of the unit-tests (logs and traces) can no longer happen as written and have been removed.

A deeper fix would likely require more refactoring, since the host (with or without port) is also used in the items ring.

Link to tracking Issue:
#10321

Testing:
Unit tests performed.
Ran test-config from the linked issue, which worked.

Documentation:
No documentation added or changed.

@jvilhuber jvilhuber requested a review from a team August 31, 2022 07:30
@jvilhuber jvilhuber requested a review from jpkrohling as a code owner August 31, 2022 07:30
@jpkrohling jpkrohling assigned jpkrohling and unassigned dashpole Aug 31, 2022
Copy link
Member

@jpkrohling jpkrohling left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This makes sense, looks like we had inconsistent values in some places. Have you experimented going the other direction? Removing the port from the existing place(s), adding it only on the backing exporter instantiation? Here:

// verify
assert.Len(t, p.exporters, 1)
assert.NotContains(t, p.exporters, "endpoint-2")
assert.Contains(t, p.exporters, endpointWithPort("endpoint-1"))
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

While the effect is the same, we should indeed assert that endpoint-2 does not exist here, as it has been removed.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure. I figured asserting that the Len is 1, and that the 1 is endpoint-1 should cover all cases. But I can revert that.

// verify
assert.Len(t, p.exporters, 1)
assert.NotContains(t, p.exporters, "endpoint-2")
assert.Contains(t, p.exporters, "endpoint-1:4317")
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This one was a good change, thanks for that!

assert.Nil(t, res)
}

func TestConsumeLogsExporterNotFound(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why was this test removed?

Copy link
Contributor Author

@jvilhuber jvilhuber Sep 1, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It no longer works. It seemed to rely on the bug I fixed, i.e. that removeMissing would remove some endpoints. There's no way to make
res := p.ConsumeLogs(context.Background(), simpleLogs())
fail in this way.

}
}

func TestConsumeTracesExporterNotFound(t *testing.T) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Same about this one.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ditto. It relied on the broken behavior to 'work'.

@jvilhuber
Copy link
Contributor Author

jvilhuber commented Sep 1, 2022

This makes sense, looks like we had inconsistent values in some places. Have you experimented going the other direction? Removing the port from the existing place(s), adding it only on the backing exporter instantiation?

No, I didn't consider that, mainly because I think that could cause issues if we wind up with an endpoint with the same hostname, but different ports, like endpoint-1:4317 and endpoint-1:4318 or something. Not sure that's realistic, but it could be configured. I can have a look, though.

Edit: It's not possible in the dns resolver, but with the static resolver? Any future resolver?

@jpkrohling
Copy link
Member

but with the static resolver? Any future resolver?

True, it's indeed realistic to have that as part of the static resolver. I think we even use that in the examples.

@jpkrohling jpkrohling merged commit 7a6f2fb into open-telemetry:main Sep 2, 2022
@jvilhuber
Copy link
Contributor Author

Fixes #10321

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

3 participants