-
Notifications
You must be signed in to change notification settings - Fork 240
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
Make throttling nmagent fetches for nodesubnet more dynamic #3023
Make throttling nmagent fetches for nodesubnet more dynamic #3023
Conversation
…de-subnet-intelligent-refresh
/azp run Azure Container Networking PR |
Azure Pipelines successfully started running 1 pipeline(s). |
…de-subnet-intelligent-refresh
/azp run Azure Container Networking PR |
Azure Pipelines successfully started running 1 pipeline(s). |
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'm going to recant some of what I said in the last PR now that I understand why we're doing this debouncing. As I mentioned during the design review, rate limits and wireserver are a fact of life, so it now feels weird to have arbitrary logic treating the nmagent client carefully because it might blow our rate limit. The design intention of the NMAgent client was always that users can do nmagent.DoSomethingForMe()
and it will block while it deals with all of the weirdness that happens with NMAgent and Wireserver. This includes async response handling... and I'm thinking it should also include respecting rate limits. If the request is going to blow the rate limit, the WireserverTransport in the NMAgent client needs to block that request until the request will succeed. Otherwise, we're just setting the user up for failure.
Doing this with tickers is definitely the right way (in particular the whole ticker resetting thing is how I've done respecting rate limits in the past). However, it should be done in https://github.com/Azure/azure-container-networking/blob/master/nmagent/internal/wireserver.go so that it's shared across the client.
…de-subnet-intelligent-refresh
/azp run Azure Container Networking PR |
/azp run Azure Container Networking PR |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run Azure Container Networking PR |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run Azure Container Networking PR |
Azure Pipelines successfully started running 1 pipeline(s). |
/azp run Azure Container Networking PR |
Azure Pipelines successfully started running 1 pipeline(s). |
…thub.com:Azure/azure-container-networking into sanprabhu/cilium-node-subnet-intelligent-refresh
/azp run Azure Container Networking PR |
Azure Pipelines successfully started running 1 pipeline(s). |
Reason for Change:
We previously added fetch of secondary IPs to the NMAgent client in CNS. This PR makes the fetch asynchronous, with the ability to adjust the frequency dynamically. Specifically,
This is implemented using a time Ticker, but we wrap it with a wrapper so as to mock it for tests. This PR also includes some additional checks for empty responses from the nmagent (this was raised in this comment). Also have UTs.
Issue Fixed:
NA
Requirements:
Notes: