Merged
Conversation
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
Signed-off-by: Eliza Weisman <[email protected]>
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
This branch updates the
linkerd2-proxy-dnscrate tostd::futureandthe latest release of
trust-dns-resolver, and updates the uses of DNSin
linkerd2-proxy-appto track the changes.For the most part, this change is pretty straightforward. However, the
std::futureversion oftrust-dns-resolverchanged how the backgroundtask driving DNS resolution is executed. Previously, it was returned by
the
AsyncResolverconstructor, but now, the constructors areasync fns that implicitly spawn the background task on the runtime thatexecutes them.
Therefore, I had to change how the DNS resolver is constructed. I opted
to build the admin runtime early and have it block on the DNS resolver
construction, and then pass that runtime to the admin thread when it is
spawned. This seemed better than making the DNS resolver lazy by making
the underlying
trust-dnsasync resolver anOptionor something, andhaving it panic when the resolver hasn't been constructed yet. Doing
that safely would have required adding a
RwLockor something, whichdidn't seem ideal.