Conversation
zmb3
requested review from
ibeckermayer
and removed request for
codingllama and
kimlisa
Tener
approved these changes
Aug 10, 2023
Contributor
Tener
left a comment
Tener
left a comment
There was a problem hiding this comment.
Looks good in general.
One thing to note is that we are changing the effective timeouts here. Previously, the system DNS had 10 seconds of timeout, the LDPA one had... unlimited? In any case tctx was only used for the former, the latter used parent ctx. Now we trim those 10 seconds to 5, and make the LDAP query run in 5 seconds flat. (Contrast with 20 seconds we have seen in the logs today.).
I think this is a good change anyway, just highlighting this to you in case this is relevant.
ibeckermayer
approved these changes
Aug 10, 2023
In environments with many desktops where some DNS queries time out, we can run in to situations where the discovery loop doesn't complete before the desktop's 10m TTL expires, causing desktops to disappear and reappear sporadically. - Increase the TTL for LDAP-discovered desktops to 30m. This won't harm UX, since desktops that stop being discovered are already purged prior to their expiration. - Perform both DNS queries (via the default resolver and by hitting the LDAP server directly) in parallel. This reduces the maximum time a single lookup can take from 20s to 5s.
zmb3
force-pushed
the
zmb3/ldap-discovery
branch
from
eb5ba12 to
c26e384
Compare
r0mant
approved these changes
Aug 10, 2023
This was referenced Aug 11, 2023
zmb3
added a commit
that referenced
this pull request
Aug 24, 2023
In #30277 we made the discovery process make two DNS queries in parallel. There was an error in this logic - since we don't write to the channel on error, if both queries fail we end up waiting a full 5 seconds even if the failures occur much quicker than that.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Aug 25, 2023
In #30277 we made the discovery process make two DNS queries in parallel. There was an error in this logic - since we don't write to the channel on error, if both queries fail we end up waiting a full 5 seconds even if the failures occur much quicker than that.
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 25, 2023
In #30277 we made the discovery process make two DNS queries in parallel. There was an error in this logic - since we don't write to the channel on error, if both queries fail we end up waiting a full 5 seconds even if the failures occur much quicker than that.
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 25, 2023
In #30277 we made the discovery process make two DNS queries in parallel. There was an error in this logic - since we don't write to the channel on error, if both queries fail we end up waiting a full 5 seconds even if the failures occur much quicker than that.
github-actions Bot
pushed a commit
that referenced
this pull request
Aug 25, 2023
In #30277 we made the discovery process make two DNS queries in parallel. There was an error in this logic - since we don't write to the channel on error, if both queries fail we end up waiting a full 5 seconds even if the failures occur much quicker than that.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Aug 25, 2023
In #30277 we made the discovery process make two DNS queries in parallel. There was an error in this logic - since we don't write to the channel on error, if both queries fail we end up waiting a full 5 seconds even if the failures occur much quicker than that.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Aug 25, 2023
In #30277 we made the discovery process make two DNS queries in parallel. There was an error in this logic - since we don't write to the channel on error, if both queries fail we end up waiting a full 5 seconds even if the failures occur much quicker than that.
github-merge-queue Bot
pushed a commit
that referenced
this pull request
Aug 25, 2023
In #30277 we made the discovery process make two DNS queries in parallel. There was an error in this logic - since we don't write to the channel on error, if both queries fail we end up waiting a full 5 seconds even if the failures occur much quicker than that.
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
4 participants
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.
In environments with many desktops where some DNS queries time out, we can run in to situations where the discovery loop doesn't complete before the desktop's 10m TTL expires, causing desktops to disappear and reappear sporadically.