-
-
Notifications
You must be signed in to change notification settings - Fork 11
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
[get.jenkins.io, azure.updates.jenkins.io] MaxMind GeoIP Rate Limit hit when redeploying/upgrading mirrorbits
chart
#4240
Comments
The idea would be to have a persistent volume to store the GeoIP data and remove the init + side containers. => shared between mirrorbits instances avoid duplicating the downloads and we keep the data instead of downloading it from MaxMin on each pod restart/re-create. Sharing a database such as this one between pods means we have to mount it as readonly in mirrorbits to avoid any write tentative. => It's already the case for the emptyDir but we should also set up the PV/PVC to be a It means we need a way to populate and update the PV data content: the GeoIP side containers should not run and be duplicated for each instance. => We need to run it as a separate deployment than mirrorbits but with only 1 replica and with the PV mounted in read+write. This separated deployement would take care or initializing and updating the database replacing the init and side container in our pods. |
Two other challenges:
|
Proposal: Let's start with a PV in non Premium Azurefile and we'll see how it behaves. If it costs too much, then we'll have to move to premium. |
Ref. jenkins-infra/helpdesk#4240 This PR adds a new PVC statically provisioned based on an Azurefile to ensure a `ReadyMany*` access mode. The goal is to have a centralized data dir. for the GeoIP database. - Using a storage account reusable for the whole cluster, hence the naming. Type is Storage v2: means billing per request: only define file shares with low workload! Signed-off-by: Damien Duportal <[email protected]>
Update:
=> Tested manually and worked (for populating the data). Need to validate the |
=> Manual test on updates.jenkins.io did work 👍 Let's roll! |
Update: let's roll for updates.jenkins.io first: jenkins-infra/kubernetes-management#5565 |
Update:
|
Caused #4261 due to the PVC errors: The The database files where stuck with SMB file handles in delete/concurrent writes 😡 . Visible in the Azure Storage Explored with: and on the |
…#844) as per jenkins-infra/helpdesk#4278 (comment) and jenkins-infra/helpdesk#4240 lets provide a write access for the kubernetes cronjob to update geoip-data
Closing as per #4278 (comment)
|
Service(s)
get.jenkins.io, mirrors.jenkins.io, Other
Summary
We recently have been hit with the GeoIP MaxMind API rate limit.
Recently, @timja received alerts about this on his own account (which we realize we were using in production - fixed in #4195 ).
We continue receiving these alerts by email every day when we perform more than 2 deployments / day of mirrorbits (either get.jenkins.io or the new azure.updates.jenkins.io Update Center system.
These rate limits are blocking our production mirrorbits instances and threatens the service of outage.
Root cause is located on the "GeoIP" addition containers running on each mirrorbit pod:
InitError
state. If it succeeds then it downloads the database once, stops and then the other pod containers are starting.Error
state.Ref. https://support.maxmind.com/hc/en-us/articles/4408216129947-Download-and-Update-Databases
Reproduction steps
No response
The text was updated successfully, but these errors were encountered: