prototype: adding option to randomly select a host from DNS#25930
prototype: adding option to randomly select a host from DNS#25930jimrollenhagen wants to merge 3 commits into
Conversation
|
Thank you for your contribution! Before we can merge this PR, please sign our Contributor License Agreement. To sign, copy and post the phrase below as a new comment on this PR.
I have read the CLA Document and I hereby sign the CLA You can retrigger this bot by commenting recheck in this Pull Request. Posted by the CLA Assistant Lite bot. |
Committed-By-Agent: claude
There was a problem hiding this comment.
💡 Codex Review
Here are some automated review suggestions for this pull request.
Reviewed commit: 4f08a2226a
ℹ️ About Codex in GitHub
Codex has been enabled to automatically review pull requests in this repo. Reviews are triggered when you
- Open a pull request for review
- Mark a draft as ready
- Comment "@codex review".
If Codex has suggestions, it will comment; otherwise it will react with 👍.
When you sign up for Codex through ChatGPT, Codex can also answer questions or update the PR, like "@codex address that feedback".
| /// - `random`: pick a single random address from the resolved set | ||
| #[configurable(derived)] | ||
| #[serde(default)] | ||
| pub(in crate::sinks::vector) dns_address_selection: DnsAddressSelection, |
There was a problem hiding this comment.
Wire DNS selection into the HTTP sink
For the scenario this change claims to address, users are sending through the http sink to a hostname with multiple DNS addresses, but this new option is scoped only to VectorConfig. The http sink still builds its client via HttpClient::new in src/sinks/http/config.rs, which goes through build_proxy_connector and HttpConnector::new() in src/http.rs, so dns_address_selection = "random" cannot be configured or applied there. As a result, the reported HTTP-sink traffic can remain stuck on the resolver's first address unless the option is plumbed into the shared HTTP client or the HTTP sink configuration.
Useful? React with 👍 / 👎.
| }); | ||
|
|
||
| let tls_for_proxy = tls_connector_builder(&tls_settings)?.build(); | ||
| let mut proxy = ProxyConnector::new(https).unwrap(); |
There was a problem hiding this comment.
Account for proxied vector endpoints
When a configured or environment proxy matches the Vector endpoint, this ProxyConnector dials the proxy URI and tunnels/forwards the original request, so the custom resolver installed on the inner HttpConnector resolves the proxy host rather than the downstream Vector hostname. In those deployments dns_address_selection = "random" silently has no effect on endpoint selection and traffic can remain pinned to whatever backend the proxy/DNS chooses; this should be rejected, warned about, or documented instead of exposing the option as if it applies to endpoint DNS.
Useful? React with 👍 / 👎.
4f08a22 to
cc00470
Compare
|
recheck |
Fixes #23121
Putting this up as a prototype for now, will discuss and iterate.
(note: used Opus 4.6 to help me work this out)
Summary
Vector configuration
How did you test this PR?
Change Type
Is this a breaking change?
Does this PR include user facing changes?
no-changeloglabel to this PR.References
Notes
@vectordotdev/vectorto reach out to us regarding this PR.pre-pushhook, please see this template.make fmtmake check-clippy(if there are failures it's possible some of them can be fixed withmake clippy-fix)make testgit merge origin masterandgit push.Cargo.lock), pleaserun
make build-licensesto regenerate the license inventory and commit the changes (if any). More details on the dd-rust-license-tool.