-
Notifications
You must be signed in to change notification settings - Fork 3
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
Implement address family affinity and prefer IPv4 by default #66
Merged
Merged
Changes from 4 commits
Commits
Show all changes
7 commits
Select commit
Hold shift + click to select a range
c7e1829
Implement address family affinity
jchadwick-buf beb8b20
Update doc comment regarding default resolver
jchadwick-buf 02c79a4
Split out address affinity routine
jchadwick-buf 8d42db8
Merge network and affinity options into policy
jchadwick-buf f26e28a
Add test for IPv4 embedded in IPv6 address
jchadwick-buf be0e6e4
Add more documentation
jchadwick-buf 1a3e1b7
Merge branch 'main' into jchadwick/prefer-ipv4
jchadwick-buf File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Oops, something went wrong.
Oops, something went wrong.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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.
I think we want this default to be controllable via env var. Maybe something like
HTTPLB_DEFAULT_ADDRESS_FAMILY_POLICY
. We can document the exact values the env var needs to have either inNewClient
or maybe it would be better indoc.go
where it talks about default behavior.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.
Hmmm... To be honest, I'm not sold on this. There are exceptions where it may be useful (a la
GODEBUG
) but in the general case I see this as a code smell. It essentially adds an implicit "impure" configuration knobs that skip the application's own configuration mechanisms. If an application wants to create a "default" resolver with one setting changed, they have to replicate this behavior too.If applications want this behavior to be controlled by environment variable, I think they ought to do it themselves.
If you insist I can add it, but is there really a good reason why reading and parsing environment variables is something
httplb
itself should do?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.
It would only be for the default, where the application has not configured anything (which will typically be unintentional, either an inadvertent omission or lack of foresight). If the application does configure it, the env var would not override.
I guess my worry is that this would never happen in practice. If they are adding code of this sort at all, then they are thinking about this and likely configuring things intentionally. More likely is that this isn't thought about or configured at all because the defaults "just worked" on day one. And then on day two, when some vendor pushes a DNS change, things break (such as in an IPv6 single-stack setup, where DNS is updated to suddenly start returning an A record). I guess I'm just used to providing knobs for certain scenarios that don't changing code, re-building, and re-deploying, as a dev ops instinct. 🤷
I guess we can leave it out. But this is the only behavior where httplb will observably differ from net/http and could do so in a way that prevents successful client->server communication, so it seemed useful. To be honest, I don't place a lot of value on "purity", especially if it potentially compromises usability or developer experience.
Anyhow, if you really don't like it, leave it out. But we definitely do need to update the docs about the change in default behavior.
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.
I think I'll hold off on adding this. I can see the operational value of a feature like this, but in practice I think that it is least surprising to users if a library has one and only one way of configuring things, through the API, rather than environment variables. If we do want to make this sort of thing configurable through environment variables, it'd probably be worth considering other things that might be worth exposing as environment variables and/or flags, possibly as a side-effect of importing an optional package, kind of like how some C++ libraries will have packages you can link to to get absl flags. I can see some arguments against this, too (it wouldn't help for people who didn't explicitly think of this, which is arguably the people who have the most to gain from the built-in ability to change a configuration knob at runtime) but ultimately I think that the better way to resolve this potential need is to make our IPv6 fallback work better in the future, so that users don't really have to think about it much more than they would for
net.Dial
andhttp.DefaultClient
.